ftrack MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.0
Disambiguation4/5
Most tools target distinct actions and resources, with clear separation between querying, CRUD, security roles, API keys, uploads, and delayed jobs. Some potential confusion exists between convenience list_* wrappers and ftrack_query, or between ftrack_convert_entity and ftrack_update, but descriptions help clarify.
Naming Consistency3/5
Most tools follow a 'ftrack_verb_noun' pattern, but there are deviations: the last five tools lack the ftrack_ prefix, 'ftrack_un_assume_user' has an awkward underscore, and delayed job tools mix nomenclature. Overall, the pattern is readable but not fully consistent.
Tool Count2/5
With 59 tools, the server is heavily over-scoped for an MCP interface. While the domain is complex, many niche operations (e.g., multiple delayed job tools, granular security role grants) could be consolidated or exposed via a more compact API surface. The count feels excessive and likely overwhelms agents.
Completeness4/5
The tool set covers a broad range of ftrack functionality: general query and CRUD, user/security management, uploads, media encoding, review sessions, task management, and project structure. Minor gaps exist (e.g., no note update/delete, no asset version creation) but core workflows are well-supported.
Average 3.2/5 across 59 of 59 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits, but it only states 'update' without mentioning permissions, side effects, status transition validation, or the return value. It provides no behavioral context beyond what the name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no fluff, but it is under-specified and merely restates the tool name. It does not earn its place by adding any informative content beyond what is already evident.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter tool, the description is incomplete. It does not explain how to obtain valid status IDs, whether the update is immediate, or what response format to expect. The lack of annotations and output schema makes this a minimal but insufficient description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing basic descriptions for task_id and status_id. The tool description adds no additional parameter semantics, but the baseline of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update the status of a task' directly restates the tool name ftrack_update_task_status. It does not add any specificity about how the status is updated, what a status ID is, or how it distinguishes from sibling tools like ftrack_update or ftrack_assign_user_to_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as ftrack_update or task assignment tools. It does not mention prerequisites, typical use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It simply says 'Create a CSV import delayed job' without mentioning that this is an asynchronous operation, what side effects occur, whether it mutates data, or what happens to the job after creation. No behavioral disclosure is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is very concise with no fluff. However, it is so terse that it sacrifices useful information; it reads more like a label than a meaningful explanation. This is acceptable but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a free-form object parameter. The description does not explain what a delayed job is, what data job_data should contain, or what the response will look like. This is completely inadequate for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the parameter has a description ('CSV import job data'), so the baseline is 3. The tool description does not add any details about the expected structure of job_data beyond the schema, so it neither enhances nor detracts from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Create') and resource ('CSV import delayed job'), and the 'CSV import' qualifier distinguishes it from sibling delayed-job tools like ftrack_export_review_session_feedback_delayed_job. However, it lacks any additional scope or details beyond what the name already implies, so it is clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, when not to use it, or which alternatives (e.g., ftrack_create or other delayed-job tools) might be more appropriate. It only states the action without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full responsibility for behavioral disclosure. It only says 'Assign a user to a task' without explaining whether existing assignments are overwritten, required permissions, or failure modes. This leaves the agent blind to side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence, front-loaded with the core action. However, it is under-specified for a mutation tool, lacking even basic guidance. While not verbose, it does not achieve the 'appropriate size' needed to be truly helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter nature, the description is minimal but insufficient. With no annotations or output schema, it fails to clarify side effects, return values, error handling, or whether the assignment replaces existing users, leaving the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with 100% coverage, providing clear descriptions for task_id and user_id. The description adds no additional meaning, but the schema already does the heavy lifting, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Assign' and the resource 'user to task', which identifies the tool's purpose. However, it does not differentiate from sibling tools like list_user_assignments or ftrack_update_task_status, lacking any scope or nuance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, no prerequisites, and no mention of how assignment relates to other task operations. The description provides no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention side effects, required permissions, whether changes are reversible, or any return value. The phrase 'Create a new entity' is essentially a restatement of the tool name and offers no additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded and efficient, though it is perhaps too brief to be maximally useful. It does not suffer from verbosity, so it scores reasonably well on conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what the tool returns, how to structure entity_data, or any side effects. A create operation typically needs to convey success/failure and resulting object information, which is entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (entity_type and entity_data) with 100% coverage. The description adds no extra meaning beyond the schema, aligning with the baseline of 3 for high schema coverage. It does not compensate for any hidden constraints or provide examples of valid entity_data structures.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Create a new entity') and identifies the resource ('in ftrack'). It is clear but does not differentiate from similar siblings like ftrack_create_note, which also creates an entity. The schema provides examples of entity types, so the purpose is understandable but lacks explicit scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as ftrack_update or ftrack_delete, nor any exclusions or prerequisites. The description simply states the action without contextual direction, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Sync LDAP users as a delayed job' without explaining what syncing entails (creation/update/deactivation), side effects, permission requirements, asynchronous execution details, or error behavior. This is a serious gap for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and easy to scan, but it lacks additional structuring such as prerequisites or parameter hints. Given its brevity, it earns a high score for conciseness, though other dimensions suffer from under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an opaque 'options' object parameter, no output schema, and no annotations. The description is far too minimal to be complete: it does not explain what options are valid, what happens after scheduling a delayed job, how to monitor it, or what the agent should expect. There is no context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the single parameter 'options' has a description ('LDAP sync options'), so baseline 3 applies. However, the description adds no extra meaning beyond the schema; 'LDAP sync options' is minimal and the object allows arbitrary additional properties, so the agent has no concrete keys or value formats. The description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Sync') and resource ('LDAP users') with mode ('as a delayed job'). It distinguishes from sibling delayed job tools by naming LDAP users specifically, though 'sync' is somewhat generic and could fail to indicate push/pull direction or update semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or mention any sibling tools (e.g., ftrack_csv_import_delayed_job) or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral implications but only says 'Configure OTP,' which implies a mutation without explaining whether it activates, resets, or requires prior setup. It does not mention permissions, reversibility, or side effects such as sending an email or overwriting existing settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise for a tool with only two parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema fully documents parameters, the description lacks information about expected behavior, return values, or usage context. For a tool that likely has side effects (configuring OTP), the absence of any guidance on prerequisites or consequences makes it incomplete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage, so the baseline is 3. The description itself adds no parameter-specific meaning, relying entirely on the schema's simple definitions of user_id and otp_type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Configure' and resource 'OTP for a user', making the core action identifiable. However, it does not differentiate from the sibling tool ftrack_configure_totp, since TOTP is a type of OTP and the distinction is left ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ftrack_configure_totp, ftrack_generate_totp, or ftrack_disable_2fa. There are no preconditions, exclusions, or mention of user state requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It merely states the action without explaining side effects (e.g., whether an email is actually sent), required permissions, idempotency, or what happens on success or failure. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded with the action and target, but it may be too terse to be maximally useful. Still, it earns a high score for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and an output schema, and the existence of closely related sibling tools, this description is severely incomplete. It lacks context about when to use the tool, what the invitation entails, and how it relates to other review session tools. The one-line description is insufficient for an AI agent to confidently select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (name, email, message, review_session_id) having a clear description. The tool description itself adds no additional parameter semantics, but the baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Send an invitation') and the resource ('a review session'), which distinguishes it from the sibling tool ftrack_send_user_invite. The verb and target are explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as ftrack_send_user_invite for user invitations or ftrack_list_review_sessions for finding session IDs. There are no usage examples, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for explaining side effects. 'Configure' is vague; it does not disclose what configuration entails, whether 2FA is enabled, if any secret is returned, or any security implications. The description is too thin for a security-sensitive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It earns its place by expanding the acronym TOTP and specifying the target, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple interface (one parameter, no output schema), the tool is security-related and has siblings that suggest a multi-step flow (generate_totp, disable_2fa). The description fails to explain the operational context, such as what happens after configuration or how this fits into 2FA management, leaving the agent without enough information to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter (user_id) with a description, so the tool description adds no new semantic meaning. Since schema coverage is 100%, the baseline score of 3 is appropriate; the description neither enhances nor obscures parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Configure TOTP') and the target ('for a user'), distinguishing it from related tools like ftrack_generate_totp and ftrack_disable_2fa by implying a setup action rather than generation or disabling. However, it lacks explicit differentiation from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites (e.g., whether generate_totp must be called first), and no context about typical use cases. This is a significant gap given the related security tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action and does not reveal side effects, required permissions, return behavior, or the default for author_id, which is only implied in the schema. This is a significant gap for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. Every word earns its place, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple nature of the tool, the description lacks essential context such as when to use it, what success looks like, or any behavioral notes. With no output schema and no annotations, the agent receives only the bare purpose and parameter names, which is inadequate for full confidence in invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each of the four parameters having a description. The tool description adds no extra semantic meaning beyond the schema, so the baseline of 3 applies without any bonus or penalty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a note on an entity' uses a specific verb ('create') and resource ('note') with a clear target ('entity'), making the core purpose immediately understandable. It is distinct from generic tools like ftrack_create by focusing on notes, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings such as ftrack_list_notes or the generic ftrack_create. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full responsibility for behavioral disclosure. It merely says 'Delete an entity from ftrack' without noting that deletion is permanent, may require elevated permissions, or could trigger cascading effects. This is a high-risk destructive operation, and the description adds no transparency beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence with no wasted words. It is front-loaded and immediately clear. However, it is so minimal that it borders on under-specification, which is why it does not receive a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params) but destructive. The description does not explain return values, error conditions, irreversibility, or permission requirements. With no output schema and no annotations, the description leaves significant gaps in understanding the full context of deletion, especially for an agent that must decide whether to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions: 'entity_id' is the ID and 'entity_type' is the type. Schema description coverage is 100%. The description adds no additional parameter context, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and the target (an entity from ftrack). This is a specific verb+resource construction that distinguishes it from sibling tools like create, update, or query. The tool name 'ftrack_delete' aligns directly with the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or disambiguation from other delete-like tools (e.g., ftrack_delete_delayed_job). The agent is left to infer that it should be used whenever deletion of a generic entity is intended, but without explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. It says 'Create a delete delayed job' but does not disclose whether the deletion is asynchronous, what the return value is, or any side effects (e.g., irreversibility). The term 'delayed' is the only hint, but it is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the core purpose without unnecessary words. It is front-loaded with the action verb 'Create' and the resource. The wording could be smoother, but it is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with no annotations and no output schema, yet the description lacks essential context. It does not explain what a 'delayed job' is, how to track it, or mention the alternative immediate deletion via ftrack_delete. An agent would have difficulty understanding the tool's role in a workflow without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters (entity_id and entity_type) clearly described. The description adds no new meaning beyond the schema, so a baseline score of 3 is appropriate. It does not explain how these parameters relate to 'batch entity deletion' beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and identifies the resource as 'delete delayed job' for 'batch entity deletion.' This distinguishes it from the sibling ftrack_delete tool, which likely performs immediate deletion. However, the phrasing 'delete delayed job' is slightly ambiguous (could be misread as deleting a job), though the purpose clarifies it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus ftrack_delete or other deletion methods. It implies use for batch deletion, but does not state prerequisites, exclusions, or scenarios where immediate deletion is preferred. The agent is left to infer usage from the name and brief description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral impacts, but it only states the operation. It does not mention whether the secret is returned, whether existing TOTP settings are overwritten, what permissions are required, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, non-redundant sentence that conveys the basic purpose efficiently. It lacks extra detail, but not at the expense of conciseness, making it reasonably well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description does not clarify what the function returns or how the generated secret relates to the user's 2FA setup. This leaves important gaps for an agent, especially given the presence of related TOTP-manipulation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter user_id (coverage 100%), and the description reiterates that the secret is 'for a user' without adding new meaning. This aligns with the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate a new TOTP secret') and the target ('for a user'), using a specific verb and resource. However, it does not differentiate this from sibling tools like ftrack_configure_totp, which may also involve TOTP secret generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as ftrack_configure_totp or ftrack_disable_2fa. There is no context about prerequisites, typical use cases, or situations to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does not state that the operation is read-only, mention authentication requirements, or describe any side effects. The minimal description lacks transparency about what the tool actually does beyond the metadata retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that earns its place. There is no redundancy, promotional content, or unnecessary detail. It is front-loaded and immediately states the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, an output schema, and any usage guidance, the description is incomplete. It does not explain what the returned metadata looks like, how it is used in the upload process, or how the parameters relate to the upload workflow. For a tool with four parameters and no output schema, this level of minimalism leaves the agent insufficiently informed to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter names and descriptions are self-explanatory. The tool description adds a small amount of context by indicating these parameters are 'required for uploading a file,' but it does not elaborate on relationships or format details beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'metadata required for uploading a file to ftrack' with a specific verb and resource. It distinguishes its role from siblings like ftrack_generate_signed_url and ftrack_complete_multipart_upload, but does not explicitly name alternatives. The purpose is understandable and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, typical invocation flow, or which sibling tools would be preferred in different scenarios. The description is purely a declarative statement of function without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'List review sessions,' which implies a read operation but adds no detail about pagination, filtering, access controls, or return format. This is minimal and not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no fluff. It is front-loaded and easy to parse, though it is arguably too sparse to provide substantial value. Still, it is appropriately concise for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward list operation with optional parameters, but no output schema exists. The description lacks any detail about what a 'review session' is, how results are returned, or how the limit and project_id parameters affect the output. It is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters (limit and project_id) clearly documented. The description itself adds no additional meaning, but given the high schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists review sessions, using a specific verb and resource. However, it does not provide any scope or distinguishing details relative to the many sibling 'list_*' tools, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like ftrack_list_projects or ftrack_list_tasks. There are no context hints, exclusion criteria, or references to alternative tools, so the agent is left without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries full responsibility for behavioral disclosure. It only states a simple listing action, but does not disclose the default limit of 100 (though present in the schema), pagination behavior, whether results are sorted, or any potential side effects. The term 'List' implies read-only, but the description does not explicitly confirm this or add context beyond the name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It is front-loaded with the verb 'List' and immediately identifies the resource and scope. Every word contributes to the core message, and there is no padding or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 optional parameters and no output schema, the description is under-specified. It does not clarify the return format (e.g., array of task entities), how filters like 'parent_id' and 'project_id' interact, or what 'context' means in hoftrack's domain model. Given the breadth of sibling list tools, this description lacks sufficient context for an agent to confidently invoke it without further schema inspection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 5 parameters, achieving 100% coverage, so the baseline is 3. The description itself does not add any parameter-specific meaning (e.g., how 'parent_id' relates to 'context'), but the schema already documents each parameter sufficiently. The description does not detract from the schema, so the baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'List tasks', and further scopes it to 'a project or context'. This differentiates it from sibling tools like ftrack_list_projects and ftrack_list_asset_versions, which target different resources. However, it does not explicitly name any siblings or provide an exclusionary qualifier, so it falls short of the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the name and description imply it is the tool for listing tasks, there is no mention of prerequisites, when to prefer it over ftrack_get_entity or ftrack_list_notes, or how it relates to the other list_* siblings. This is a minimal viable description but lacks adoption guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention the default exclusion of inactive users, pagination via the limit parameter, or any permission requirements. The phrase 'all users' contradicts the schema's default for include_inactive, which is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just three words ('List all users') with zero wasted text. It is appropriately sized for a simple list operation, though brevity sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is under-specified. It doesn't explain the default active-only behavior, what fields are returned, or when to prefer this over ftrack_query. The 'all users' wording could mislead an agent into expecting inactive users by default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (limit and include_inactive), so the description adds no additional parameter semantics. The baseline of 3 is appropriate since the schema fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('users'), distinguishing it from other list tools like ftrack_list_projects and ftrack_list_tasks. However, the word 'all' is misleading because the include_inactive parameter defaults to false, meaning it lists only active users by default.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as ftrack_query or ftrack_search. The description does not mention scenarios, prerequisites, or exclusions, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'check', which implies read-only behavior, but does not explicitly state it. No disclosure of return format, whether it checks the current user's permissions, or any security requirements. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that earns its place. It is concise and to the point without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple but multi-param tool with no output schema and no annotations, the description is insufficient. It does not explain what the tool returns (e.g., boolean, list of allowed actions), how to interpret results, or detail that it operates on the current user. The agent lacks enough context for correct invocation and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any meaning beyond the schema's parameter descriptions. It does tie entity_type/entity_id together via 'for an entity', but gives no extra details about valid actions or entity types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check permissions for an entity' uses a clear verb ('check') and resource ('permissions'), but lacks specificity about whose permissions are checked or the scope. It does not explicitly distinguish from sibling permission management tools, though 'check' contrasts with create/update/revoke operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of use cases like verifying access before an operation or prerequisite conditions. The agent is left to infer from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not mention return format, permissions, or behavior when project_id is omitted, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, free of verbosity and easy to parse. It is appropriately front-loaded, though it could benefit from slightly more substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with no output schema and minimal annotations. It doesn't explain what 'storage usage information' means, whether it returns global or per-project data (aside from the schema), or any limitations, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter with a clear description, so the description doesn't need to add parameter details. Baseline score of 3 is appropriate due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with a specific resource ('storage usage information'), clearly indicating the tool retrieves storage usage data. It is distinct from sibling tools, though it doesn't elaborate on scope like project versus global.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as ftrack_query or list_* tools. It lacks context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it fails to mention any traits such as error handling, idempotency, required permissions, or consequences of updating a non-existent entity. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It front-loads the action and resource, and every word earns its place. Perfect conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature, absence of annotations, and lack of an output schema, the description is far too minimal. It does not address success/failure behavior, return values, or any nuances of the update operation, leaving the agent with insufficient context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the description does not need to add parameter-level detail. The description itself adds no meaning beyond the schema, but the schema already provides sufficient semantics, keeping the score at baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Update') and resource ('existing entity in ftrack'), making the core purpose understandable. However, 'entity' is generic and does not distinguish this from other update tools among siblings (e.g., ftrack_update_task_status, ftrack_update_user_security_role).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, no exclusions, and no context about typical use cases. It only states the action without any decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only hints at toggling active state but does not explain mutation semantics, permission requirements, idempotency, or side effects. This is inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It communicates the core purpose efficiently and is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with no annotations and no output schema. It lacks information about return values, error scenarios, prerequisites, and when to use it relative to sibling tools like ftrack_add_user_security_role or ftrack_remove_user_security_role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with basic descriptions for all three parameters. The description adds minimal value beyond the schema—only an example of activate/deactivate which maps to the is_active field. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'user security role', with an example of activate/deactivate that clarifies the meaning. It is distinguishable from sibling tools like add/remove, though it does not explicitly name the alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus adding, removing, or granting roles. The description does not mention prerequisites, such as the role already being assigned to the user, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It simply states 'List milestones' without disclosing whether authentication is needed, whether results are paginated, or if there are side effects. The read-only nature is implied but not explicit, and no error behavior or rate limits are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets straight to the point. It is front-loaded with the verb and resource, making it easy to scan. No unnecessary words or restatements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and relies on the description to convey return values and usage context. The description does not clarify whether project_id is required, how the limit default works, or what response format to expect. For a list operation with multiple optional filters, this lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the three parameters (limit, status, project_id) with descriptions, achieving 100% coverage. The tool description itself adds no parameter information beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing milestones for a project. It distinguishes from sibling list_* tools by specifying the resource 'milestones' and the scoping 'for a project'. It lacks an explicit scope qualifier like 'all' but is unambiguous enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives. It does not mention any exclusions, prerequisites, or conditions, leaving the agent to infer usage solely from the name. With many sibling list_* tools, explicit differentiation would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of disclosing behavioral implications. It only says 'convert,' but does not mention whether the operation is destructive, reversible, requires special permissions, or affects related data. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded and easy to parse, though it could benefit from more explanatory content—but that is a completeness issue, not a conciseness flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three required parameters, no output schema, and no annotations. The description is too minimal to be complete for an agent: it does not explain the return value, side effects, prerequisites, or any constraints on conversion. This leaves significant contextual gaps for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (entity_id, entity_type, target_type) at 100% coverage. The tool description adds no additional parameter semantics beyond what the schema already explains, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Convert') and resource ('entity') with a clear scope ('from one type to another'), distinguishing it from siblings like ftrack_create, ftrack_update, and ftrack_delete. It immediately conveys the core action without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, no exclusions, and no context about typical conversion scenarios. The description merely states what it does, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries full burden for behavioral disclosure. While 'delayed job' hints at asynchronous execution, it does not explain side effects, return behavior, job status monitoring, or permissions. The description is too sparse to inform the agent of what happens after export.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words, making it highly concise. However, it is perhaps too terse to be fully effective given the complexity of a delayed job, though this is more a completeness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description does not explain the return value, job lifecycle, or how to check export results. With only a one-sentence description, the context is insufficient for an agent to fully understand the tool's behavior and outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('options' and 'review_session_id') having descriptions. The tool description adds no additional parameter context, so the schema already carries the semantic weight; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Export'), resource ('review session feedback'), and mode ('as a delayed job'), which distinguishes it from other delayed job tools like ftrack_csv_import_delayed_job. This unambiguously identifies the tool's primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, exclusions, or specific scenarios. There is no explicit or implied usage context beyond the literal action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses only that it is a delayed job, but does not explain job lifecycle, how to monitor/retrieve results, side effects on existing structure, permissions, or whether it is destructive. This is insufficient for a syncing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundancy. It is front-loaded with the core action. The brevity is not excessive but is more under-specification than elegant conciseness, so a 4 is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a free-form options object, the description is incomplete. It does not mention what the tool returns (e.g., job ID, success status), how to retrieve job status, or what effects the sync has. This is a significant gap for a delayed job tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both project_id and options described, giving a baseline of 3. However, the options description ('Sync options') is vague and the tool description adds no further parameter meaning, so it does not elevate beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Sync), the resource (structure), the destination (iconik), and the mode (delayed job). It distinguishes from siblings like get_project_structure by specifying the external destination and asynchronous nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over other delayed job tools or alternatives. It does not mention prerequisites, exclusions, or context such as 'use this when you want to push structure to iconik without waiting for completion.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It only states 'Execute a query' and provides an example, without revealing whether it is read-only, what it returns, potential side effects, permissions needed, or result limits. It adds little beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and includes a helpful example. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is adequate but minimal. It lacks information about the return format, whether queries are read-only, and how this tool relates to other query/search tools. Since there is no output schema, more context would help the agent set expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the 'expression' parameter with an example. The description adds a slightly richer example with a WHERE clause, but this is marginal. It meets the baseline 3 but does not substantially enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a query using ftrack query language, with a concrete example. It distinguishes from siblings like ftrack_parse_query (which likely parses queries) and ftrack_search (which may be a friendlier search), but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The example implies usage, but there is no mention of appropriate scenarios, exclusions, or comparison to related tools like ftrack_search or ftrack_parse_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only states the action, but does not explain side effects (e.g., whether it sends email, invalidates current password, requires admin rights). For a reset operation, this lack of transparency is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient single phrase, easily parsed. However, it is almost terse, with no extra structuring needed for a one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema but no annotations or output schema. The description is too minimal to cover the implications of a password reset, such as consequences for the user's session or notification. It fails to provide adequate context for an agent to use it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with a simple 'User ID' description. The description adds little beyond mentioning 'user', but the parameter is self-explanatory. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'Reset' and the target 'user remote password'. Distinguishes from siblings like ftrack_reset_remote_api_key by specifying password rather than API key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Sibling tools include user invite and API key reset, but description does not mention when password reset is appropriate or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of disclosing behavior. It merely says 'full-text search' without mentioning return format, permissions, pagination, or any limitations. This is minimal and non-misleading but lacks substantial context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, efficiently front-loading the core function. While it could be more detailed, it earns its place as a concise summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having five parameters and no output schema or annotations, the description offers no information about how parameters interact, what results look like, or how it relates to similar tools. This is insufficient for an agent to use it effectively without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with all five parameters adequately described. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: full-text search across ftrack entities. The term 'full-text' distinguishes it from sibling tools like ftrack_query, which likely handles structured queries, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as ftrack_query or list_* tools. The description only states what it does, leaving the agent to infer the appropriate context without any explicit recommendations or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the core action (sending an invitation email) but does not mention side effects, required permissions, idempotency, or failure modes. For a mutating operation that sends email, this is minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and contains no unnecessary words. It efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers high-level purpose but leaves out important context like what happens after sending, whether email is required, and any error conditions. Without annotations, additional behavioral detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (email optional, user_id required) with 100% coverage. The description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send an invitation email') and target ('to a user'), making the purpose unambiguous. It differentiates from the sibling ftrack_send_review_session_invite by specifying 'user' rather than 'review session', though it doesn't explicitly call out the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives (e.g., ftrack_send_review_session_invite), any prerequisites, or exclusions. It only states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does not disclose whether encoding is asynchronous, what the return value indicates, or any side effects or permissions needed. The single sentence states only the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero fluff. Every word earns its place and the sentence directly conveys the core action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a free-form options object and no output schema or annotations. The description doesn't explain what the options might contain, whether the operation is asynchronous, or how to track progress. This is inadequate for a triggering action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with descriptions ('Component ID to encode' and 'Additional encoding options'), so schema coverage is 100%. The description adds no parameter-specific semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Trigger') and names the resource ('media encoding/transcoding for a component'), making the tool's purpose clear. It distinguishes itself from sibling tools like ftrack_create or ftrack_update, which handle general CRUD operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or context about typical workflows. The description only states the action without helping the agent decide if this is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral context. It does not mention whether generating a signed URL has side effects, requires authentication, or produces expiring URLs. The description only states the action, not the implications, which is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no redundant information. It is front-loaded with the key action and resource, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should clarify the return value (e.g., a URL string or a structured object with expiration). It also does not explain how this tool fits into the broader upload/download workflow or what prerequisites exist. The description is too terse to be fully complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for both parameters. The description adds minimal context by mapping 'accessing' to 'get' and 'uploading' to 'put', but this is already explicit in the schema's operation enum description. Thus the description provides no significant additional parameter semantics beyond the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: generating a signed URL for accessing or uploading a component. The verb 'generate' and resource 'signed URL' are specific, and the mention of 'accessing or uploading' distinguishes it from siblings like ftrack_get_upload_metadata or ftrack_complete_multipart_upload, which deal with other aspects of uploads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, integration with upload flows, or when to choose it over related tools. With dozens of siblings, this lack of context leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It merely states the grant action without mentioning side effects, idempotency, permission requirements, or whether existing grants are replaced. For a mutating operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundant information. It communicates the essential action efficiently and earns its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, the description is too sparse. It does not explain return values, prerequisites (e.g., whether the API key exists), or post-conditions (e.g., whether access is additive). Sibling tools like revoke suggest a broader access-control context that is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete coverage (100%) with descriptions for both parameters ('API key ID' and 'Project ID to grant access to'). The tool description adds no extra semantic detail beyond what the schema already states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Grant an API key access to a project' uses a specific verb ('grant') and clearly identifies the resource and target (API key to project). It distinguishes itself from siblings like ftrack_revoke_api_key_project and ftrack_grant_api_key_security_role by its unique action and resource combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as revoking access or granting security roles. The description states only the action, leaving the agent to infer usage context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, idempotency, whether existing roles are replaced or added, or any permission requirements. This is a state-changing operation and the description is notably lacking in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly states the purpose without any redundant or filler content. It is front-loaded with the action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation with no annotations and no output schema, the description should provide more context about behavior and edge cases. It does not clarify how this tool differs from similar siblings, nor does it indicate expected outcomes or failure modes. The schema is simple, but the description is too minimal for an agent to reliably invoke this tool in the right context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a description for all three parameters, achieving 100% coverage. The tool description adds no extra meaning beyond the schema's field descriptions. Per the baseline, since schema coverage is high, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Grant' and clearly identifies the resource: user security role access to a specific project. It distinguishes itself from sibling tools by emphasizing the project-specific scope, which is not explicit in other similar tool names like ftrack_add_user_security_role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or why one might choose this over ftrack_add_user_security_role or other security role tools. There is no implied usage beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of conveying behavior. The verb 'List' strongly implies a read-only operation, which is a key behavioral trait. However, it does not disclose other relevant details such as whether both task_id and asset_id can be used together, or any limitations on the query scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded with the action and contains no unnecessary words. It is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context about return values and filter behavior. It does not explain what the response contains, whether both filters can be combined, or how limit influences results. The description is too sparse for a tool with no other behavioral documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value by hinting that versions are scoped by task or asset, which maps to task_id and asset_id. It does not clarify the limit parameter or the relationship between the two filter parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List') and resource ('asset versions'), and provides scoping context ('for a task or asset'). It is specific and understandable, but does not explicitly differentiate from sibling list tools, though the resource is unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, and does not mention any prerequisites or exclusions. It only states what it does, not the appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List' implies a read operation, but the description does not explicitly state that it is non-destructive, nor does it mention pagination, ordering, or any other behavioral traits such as whether only certain entity types are supported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with no output schema and no annotations, but the description is still under-specified. It does not mention note ordering, response format, valid entity types, or any limitations. The agent is left without enough context to fully predict the tool's behavior beyond the literal 'list notes'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's own parameter descriptions ('Entity type', 'Entity ID', 'Maximum number of notes to return'). The description's 'for an entity' aligns with the required parameters but offers no extra depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('notes') with a scope ('for an entity'). It is specific enough to distinguish from sibling tools like ftrack_list_projects, ftrack_list_tasks, and ftrack_list_users because it targets notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like ftrack_query or ftrack_search. It does not mention which entity types support notes, any prerequisites, or when this tool is preferable over other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the operation (list projects) and gives no behavioral details such as read-only nature, return format, pagination behavior, or whether archived projects are excluded by default. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the primary action 'List all projects' and a brief qualifier. There is zero wasted content; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is minimal but lacks crucial context: no mention of return fields, default filtering behavior, permissions, or how 'all projects' is scoped. Since there is no output schema and no annotations, the description alone is insufficient for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both 'limit' and 'include_archived' having adequate descriptions. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List all projects' with a specific verb and resource. The parenthetical 'convenience wrapper for query' hints at differentiation from ftrack_query, but it doesn't explicitly name sibling alternatives or distinguish from similar list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a simple alternative to ftrack_query via 'convenience wrapper for query', but it does not explicitly state when to use this tool over alternatives or when not to use it. The guidance is merely implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action ('reset') but does not disclose consequences like whether the existing key is invalidated, permissions required, reversibility, or notification side effects. The description adds no behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately sized for a simple tool, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is too sparse. It lacks context about what a 'remote API key' is, the implications of resetting it, and when it should be used. The one-line description does not sufficiently equip an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required parameter 'user_id' with description 'User ID', so schema_description_coverage is 100%. The description adds no additional parameter semantics, but the baseline of 3 applies because the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reset a user remote API key' uses a specific verb ('reset') and resource ('user remote API key'), clearly stating the action. It distinguishes from sibling tools like grant/revoke API key or reset remote password, as it targets resetting an API key specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as granting/revoking an API key or resetting a password. The description does not mention any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral implications, but it only states the action without disclosing side effects, permission requirements, or reversibility. For a security-sensitive mutation, this lacks important context. It does not contradict any annotations since none are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's function. It is front-loaded with the verb and resource, with no wasted words. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description states the core function but omits operational context such as whether the action requires administrative privileges or what happens to the user's 2FA recovery codes. It is adequate but not fully comprehensive for a security-related mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete coverage for the single 'user_id' parameter with description 'User ID'. The tool description adds 'for a user', which aligns with the parameter but doesn't provide additional format or usage semantics. Baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Disable' and clearly identifies the resource 'two-factor authentication for a user'. It distinguishes from sibling tools like ftrack_configure_otp and ftrack_configure_totp, which manage 2FA settings rather than disable them. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as ftrack_configure_otp or ftrack_reset_remote_api_key. It doesn't mention prerequisites like admin permissions or the context in which disabling 2FA is appropriate. There are no explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure. 'List all security roles' implies a read-only operation but does not mention permissions, whether the list is exhaustive, ordering, or return format. Minimal behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is entirely front-loaded with the essential action and resource. Every word earns its place, and there is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema and lack of output schema, the description is nearly complete for selecting and invoking the tool. It could benefit from mentioning what a security role is or what data is returned, but that is not essential for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is 100% covered (empty). The description correctly aligns with the fact that no parameters are needed. This is the baseline case for a no-parameter tool, and the description adds sufficient clarity by noting 'all'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'security roles' and scope 'all'. It is distinct from sibling tools that operate on other entities, though it does not explicitly name alternatives or differentiate itself beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context such as 'use this to get all roles without filtering'. The description states only the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It only states the action, but does not mention idempotency, side effects, required permissions, or behavior when the role is not assigned. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It effectively communicates the core purpose without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two fully described parameters, so the description is minimally sufficient. However, there is no output schema, no usage context, and no behavioral details, which leaves gaps in completeness for an agent deciding to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters are described in the schema. The description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a security role from a user' uses a specific verb and resource, clearly distinguishing it from sibling tools like add/update/grant security roles. It precisely identifies the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as ftrack_revoke_user_security_role_project. The description does not mention exclusions or context where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states the core action but does not mention side effects (e.g., whether the API key is deleted, if the action is reversible, or if special permissions are required). For a mutating operation, more transparency is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundancy. It is front-loaded with the verb 'Revoke' and immediately states the object and scope. It earns its place with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with two required parameters and no output schema. The description is minimally adequate, but it omits behavioral context (e.g., consequences of revocation) that would help an agent fully understand the operation. Given the lack of annotations, the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters (api_key_id and project_id), so the schema already explains their meaning. The description adds no additional parameter-level context beyond what the schema provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Revoke') and clearly identifies the resource ('API key access') and the context ('from a project'). It distinguishes this tool from siblings like ftrack_revoke_api_key_security_role and ftrack_grant_api_key_project by specifying the project scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or suggest when to prefer this over ftrack_revoke_api_key_security_role or ftrack_grant_api_key_project. Usage context is only implied by the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('revoke') but gives no information about side effects, reversibility, permission requirements, or impact on the API key's access. This is insufficient for an agent to anticipate consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the action. No wasted words or redundant information. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters and no output schema, so the description could be short. However, it lacks usage context, such as when to revoke a security role or how this interacts with other API key operations. This makes it minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with both parameters described ('API key ID' and 'Security role ID to revoke'). The description adds no additional parameter context, so the baseline score of 3 applies. This is acceptable because the schema already provides clear semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'revoke' and the resources involved ('security role from an API key'). It distinguishes from sibling tools like 'ftrack_revoke_api_key_project' by explicitly mentioning security role versus project. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'ftrack_grant_api_key_security_role' or other revocation tools. The description does not mention prerequisites, complementary actions, or scenarios where this tool should be preferred. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It discloses that only top-level children are returned, but omits details like return format, pagination behavior beyond limit, error handling, or whether nested items are excluded. This is a significant gap for a retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without filler. Every phrase earns its place, making it efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema), and the description gives a basic idea of the return content. However, with no annotations and no output schema, the agent may not know the exact response shape or edge-case behaviors. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context by specifying 'top-level' and examples of children, but does not add significant meaning beyond the schema's parameter descriptions. It adequately supports understanding without exceeding the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the top-level structure of a project, with immediate children examples (sequences, episodes, folders). It is specific about verb and resource, but does not explicitly contrast with sibling tools like get_entity, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when you need top-level project structure—but provides no explicit guidance on alternatives or exclusions. The context is clear enough for basic selection, but lacks depth found in better-calibrated tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing behavior. The verb 'List' clearly implies a read-only operation, which is a basic transparency signal. However, it does not mention any additional context such as access requirements, pagination behavior, or whether the result is limited to the current project context. This is acceptable for a simple list but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that contains no filler. Every word earns its place: 'List' specifies the action, 'asset builds' the resource, and 'for a project' the context. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 optional parameters fully documented in the schema, no output schema, and no annotations. The description is adequate for a straightforward list operation, but it lacks any information about return format, ordering, or relationship to project_id. It is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented in the schema. The description adds no further meaning beyond the schema, so the baseline of 3 is appropriate. The parameter names and descriptions are self-explanatory (limit, status, asset_type, project_id).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('asset builds') with a scoping phrase ('for a project'), making the core function clear. However, it does not distinguish from sibling tools like ftrack_list_asset_versions or list_shots, so it misses the differentiator needed for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Given the many sibling list tools (e.g., ftrack_list_asset_versions, list_shots), the description fails to explain what makes asset builds distinct or when to choose it over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It indicates a read-only enumeration and 'all available' implies no filtering, but it does not mention output structure, pagination, permissions, or whether 'available' means permission-scoped. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence containing exactly the essential information; no filler. It is front-loaded and easily parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is acceptable but thin: it does not describe the shape of returned status objects or clarify the relationship to status assignment workflows. Since there is no output schema, that information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is empty, so no parameter documentation is required. The baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'statuses' and scope 'all available', making the action clear. It is distinct from sibling list tools by naming statuses, though it does not explicitly contrast with ftrack_list_types or ftrack_list_priorities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ftrack_list_types or ftrack_list_priorities. There are no usage conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action, not side effects, idempotency, potential errors, security permissions, or what happens if the role already exists. For a mutation tool, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically complete sentence with no redundant words. It is properly sized for the simple operation it describes, though it could add value without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters fully described in the schema and no output schema, the description covers the core purpose. However, it lacks context about return values, error behavior, prerequisites (e.g., user and role must exist), or relationship to sibling tools, leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters described ('User ID' and 'Security role ID to add'). The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and identifies both the object ('security role') and the target ('user'), clearly distinguishing this from sibling tools like ftrack_remove_user_security_role and ftrack_update_user_security_role. It is immediately obvious what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case by its verb and object, but provides no explicit guidance on when to choose this over alternatives, no exclusions, and no mention of prerequisites. With siblings like 'grant security role project' and 'update user security role', a note about intended use would help, but the name is self-explanatory enough for a minimal 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool completes a multipart upload but does not explain side effects, idempotency, error behavior, or the outcome if parts are missing. For a mutation action, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and condition. Every word contributes meaning with no filler or redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with well-described schema parameters and a key precondition in the description. However, with no output schema and no details about return values or failure modes, the description is not fully complete for an agent that needs to handle outcomes. It is minimally viable but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all three parameters (component_id, upload_id, parts) clearly described. The description does not add any parameter-specific details beyond the action, so the schema fully handles parameter semantics. A baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Complete') and the resource ('a multipart upload'), along with the precondition that all parts have been uploaded. It is unambiguous and distinct from sibling upload-related tools, though it does not explicitly name alternatives, preventing a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit condition for use: 'after all parts have been uploaded'. This gives the agent clear context on when to invoke the tool. However, it does not mention any when-not-to-use scenarios or alternative tools, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states only the action and does not disclose whether the grant replaces or adds to existing roles, whether permissions are required, what the result of granting is, or if it is reversible. This is minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, clearly front-loaded with the action and object. It contains no unnecessary words or repetition and is appropriately concise for a simple mutation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low in complexity with fully documented parameters, but the description omits any context about prerequisites, behavioral effects, or return values. While not severely incomplete, it is minimally adequate and would benefit from a note specifying global scope or that the role is applied immediately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions for both api_key_id and security_role_id. The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb ('grant') and resource ('security role to an API key'), distinguishing it from sibling tools like revoke or project-scoped grants. While the scope (global vs. project) is not explicitly stated, the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool name and description (granting a security role to an API key), but there is no explicit guidance on when to choose this over alternatives such as ftrack_grant_api_key_project or ftrack_add_user_security_role. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List all available task/object types' implies a read-only operation, but it does not disclose what the returned data looks like (e.g., just names, schema details, or nested structures). Since this is a simple no-parameter list operation and the description does not contradict any annotation, a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the verb and resource. Every word is meaningful, with no redundancy or filler. It is highly concise and well-structured for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with no parameters and no output schema. The description adequately conveys the operation, but given the presence of many sibling list tools, a small addition about what 'types' are used for (e.g., entity type identifiers in queries) would improve completeness. Essentially, it is complete for a zero-parameter list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is trivially 100%. With no parameters to describe, the baseline is 4, and the description does not need to add parameter semantics. There are no missing parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource as 'all available task/object types', distinguishing it from sibling list tools that list concrete entities like projects or tasks. However, 'task/object types' is slightly vague—it could refer to entity schemas, status types, or other categorizations—but it still conveys the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given the many sibling list tools (e.g., ftrack_list_projects, ftrack_list_tasks, ftrack_list_statuses), there is no clarification that this tool lists type definitions or categories rather than specific instances. The description gives no context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Query' implies a read-only operation, it does not mention return format, potential limits, or any other behavioral traits, leaving significant gaps for a tool that fetches all schemas.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action ('Query'). It contains no unnecessary words and is entirely on-topic, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema, the description should ideally clarify what the query returns. It does not specify the structure or purpose of entity schemas, leaving some ambiguity. Given the low complexity, a 3 is appropriate—adequate but with a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to explain. Per the baseline rule for 0-parameter tools, the description adequately covers this aspect, deserving a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Query' and identifies a clear resource: 'all available entity schemas'. This clearly distinguishes it from sibling tools like ftrack_query and ftrack_parse_query, which focus on entities and query parsing respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description simply states the function without any context about use cases, prerequisites, or exclusions, providing no actionable direction for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the admin privilege requirement but omits critical behavioral details: whether the identity assumption persists for subsequent calls, whether it must be reverted with ftrack_un_assume_user, or any side effects. This is a significant gap for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that is front-loaded with the verb and resource, and the parenthetical adds a crucial constraint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but as a state-changing operation, the description lacks essential context about the scope and duration of the identity assumption. With no output schema and no annotations, more instruction is needed for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with user_id described as 'User ID to assume'. The description adds no additional parameter meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Assume another user identity') with a specific resource (user identity) and a key prerequisite (admin privileges). It distinguishes from sibling tools like ftrack_un_assume_user and other user management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied use case is clear for impersonation, and 'requires admin privileges' signals a prerequisite. However, it does not explicitly state when to use versus alternatives like ftrack_un_assume_user or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It only states 'List' (implying read-only) but gives no detail about pagination limits, default behavior, response format, or constraints like requiring at least one filter. This is a significant gap for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with the verb and object front-loaded. It contains no filler or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is adequate given the schema covers all params. However, with no output schema and no annotations, a brief note on return value or default limit would improve completeness, though it is not strictly necessary for low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented. The description adds a mapping between 'project or parent sequence' and the project_id/parent_id filters, but offers no additional semantic depth beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with the resource 'shots' and scopes it to 'a project or parent sequence', clearly distinguishing it from sibling tools that list other entity types (e.g., list_tasks, list_asset_builds).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to fetch shots under a project or sequence, but provides no explicit guidance on when to choose this over alternatives or any exclusions. It is minimally conveyed rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the key behavior of atomicity (all succeed or all fail), which is essential. However, it does not describe the return value, ordering semantics, or potential side effects beyond the transaction guarantee.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and includes a clarifying parenthetical about transactional behavior. Every word earns its place without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested operations array) and the absence of an output schema or annotations, the description is too sparse. It does not explain what the tool returns, how results are aggregated, or any practical constraints (e.g., maximum operations, error handling beyond rollback). This leaves important gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters and their purposes. The tool description adds no additional parameter-specific meaning, but that is acceptable given the schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes multiple operations in a single transaction, which is a specific verb+resource+scope. It distinguishes itself from sibling tools like ftrack_query or ftrack_create by emphasizing the batch/transactional nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when multiple operations need to be executed atomically. It provides clear context about the transactional guarantee but does not explicitly mention alternatives or when not to use it, e.g., for a single operation, one would use the corresponding individual tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states the action without disclosing side effects, required permissions, or reversibility. This is minimal behavioral disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that is precise and free of filler. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three well-documented parameters and no output schema. The description captures the essential scope and action. While it could mention success behavior or permissions, the minimalism is acceptable for this straightforward revoke operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema (100% coverage). The description adds no additional semantics beyond the schema, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Revoke' and identifies the exact resource 'user security role access' with a clear scope 'from a specific project'. This distinguishes it from siblings like ftrack_remove_user_security_role (global) and ftrack_revoke_api_key_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from a specific project' implies this is for project-scoped revocation, contrasting with general revocation tools. However, no explicit alternatives or exclusions are named, so guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'List' implies a read-only operation, but it does not explicitly state safety or disclose that 'all' tasks is subject to the 'limit' parameter (schema default 100). The phrase 'List all tasks' could mislead an agent into expecting unpaginated results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core operation and the two optional filters efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no annotations, and no output schema. The description explains what it lists and the filters, but lacks details about pagination, the return format, or the effect of the 'limit' parameter on 'all tasks'. This is adequate for a simple list tool but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description. The description restates that project and status can be filters, but adds no new meaning beyond the schema. The 'limit' and 'user_id' semantics are left entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource as 'tasks assigned to a user', with optional filters. This distinguishes it from sibling tools like ftrack_list_tasks (general task listing) and ftrack_assign_user_to_task (assignment mutation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for listing a user's assignments with optional project/status filters. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous enough for an agent to decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It adds behavioral detail by specifying 'single entity' (returns one object) and 'with specified projections' (returns only requested fields). However, it does not disclose error behavior, permissions needed, or response format, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that starts with the verb 'Get', making it immediately clear what the tool does. It contains no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read operation with full schema coverage and no output schema. The description clarifies the projection behavior, which is the main non-obvious aspect. However, it does not describe the return format or error behavior, but this is acceptable for such a focused tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, so the baseline is 3. The description's mention of 'specified projections' reinforces the optional projections parameter but adds no new details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a resource ('a single entity'), and the method of identification ('by type and ID'), while also mentioning the optional projection behavior. This clearly distinguishes it from siblings like ftrack_query or ftrack_search, which are for broader queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool retrieves one entity by type and ID, which provides clear context for when to use it. However, it does not explicitly mention alternatives or when not to use it, even though sibling tools like ftrack_query exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It adds the scope 'all available,' indicating no filtering or parameters, and 'list' implies a read-only operation. However, it doesn't disclose the output format or any side effects, though for a simple list tool this is somewhat sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence: "List all available priorities." Every word is necessary, and it is front-loaded with the verb 'list.' This is an ideal example of conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema, no annotations), the description adequately captures its function. It tells the agent that the tool lists all priorities, which is enough to select and invoke it. The only minor gap is not describing the return structure, but that is not critical for such a basic listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. Per the rubric, 0 parameters gives a baseline of 4. The description doesn't need to explain parameters, and it correctly implies there are no inputs by saying 'all available' without any filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "List all available priorities" clearly states the verb (list), the resource (priorities), and the scope (all available). It distinguishes itself from sibling tools like ftrack_list_statuses and ftrack_list_types by explicitly naming 'priorities' as the resource, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if you need a list of all priorities, call this tool. However, it provides no explicit context for when to use it over alternatives (e.g., statuses or types), nor does it mention any exclusions. This is baseline implied usage, not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation via 'Get' and lists the returned information (version, configuration). However, with no annotations, it does not disclose potential caveats such as required permissions, whether configuration includes sensitive data, or any operational side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and free of redundancy. It efficiently communicates the operation and expected content with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (0 params, no output schema), the description is sufficient for an agent to understand the tool's purpose. It could specify the exact response format or mention any prerequisites, but that is not critical for this basic info retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides full coverage (100%). The description adds no parameter syntax details, but the baseline for zero-parameter tools is 4, and the description adequately indicates what the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with a clear resource ('ftrack server information') and adds specifics ('version and configuration'). It effectively distinguishes this tool from siblings like ftrack_query or ftrack_query_schemas by focusing on server metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implicitly clear for retrieving server info, but the description does not explicitly state when to use this tool versus other query/info siblings, nor does it mention any exclusions. It relies on the tool's name and general context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the crucial non-execution behavior, which is a safety-relevant trait, and indicates the validation use case. However, it doesn't describe return values or error handling, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and immediately clarifying the non-execution behavior. No wasted words, and the structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without output schema, the description covers purpose and the non-execution safety aspect. However, it does not state what the function returns (e.g., a parsed structure, validation status, or error), which is a notable gap given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'expression' parameter as 'Query expression to parse' with 100% coverage. The tool description does not add additional semantic detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'parse' with a resource 'query expression', and explicitly notes it does not execute the query, clearly distinguishing it from execution tools like ftrack_query. This provides unambiguous purpose and differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without executing it (useful for validation)' implies when to use this tool: to validate a query expression without side effects. It contrasts with execution-oriented sibling tools, though it doesn't explicitly name alternatives that execute queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full transparency burden. It states the core behavior (returning to original identity) but does not disclose what happens if no identity is currently assumed, whether the action is reversible, or any side effects. This is a simple state change, but the description leaves some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded and contains no superfluous information. Every word contributes to understanding the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description is largely complete. It clearly states the purpose and outcome. However, it omits any note about the prerequisite of being in an assumed state or behavior when not, which would make it fully comprehensive. Still, it is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 is appropriate because there is nothing to add beyond what the empty schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Stop assuming') and resource ('another user identity'), clearly indicating the tool reverts an identity assumption. It inherently distinguishes itself from the sibling tool ftrack_assume_user, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this should be used when currently assuming another user's identity, as stated by 'Stop assuming another user identity'. It does not explicitly mention alternatives, but no real alternatives exist for this action. It lacks an explicit 'use after assume_user' statement, hence not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ftrack-mcp MCP server](https://glama.ai/mcp/servers/VFX-Tools-LLC/ftrack-mcp/badges/card.svg)](https://glama.ai/mcp/servers/VFX-Tools-LLC/ftrack-mcp)

Score Badge

Copy to your README.md:

[![ftrack-mcp MCP server](https://glama.ai/mcp/servers/VFX-Tools-LLC/ftrack-mcp/badges/score.svg)](https://glama.ai/mcp/servers/VFX-Tools-LLC/ftrack-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/VFX-Tools-LLC/ftrack-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server