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

No annotations are provided, so the description carries full burden for behavior disclosure. It transparently states it scans and reports rather than mutates, and details the exact statuses and thresholds it will surface ('ARCHIVING stuck >24h', 'FAILED_TO_ARCHIVE'). The main gap is not explicitly stating that it is read-only, but 'scan and report' strongly implies non-destructive behavior.

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

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

The description is a single concise sentence that leads with the main action and then uses a colon to enumerate specifics. Every clause adds meaningful detail without filler.

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

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

With one paramer, no output schema, and no annotations, the description gives most essential context: it reports grouped statuses, flags an age threshold, and identifies failed assets. It does not describe output formatting or error conditions, but the enumerations of report contents cover the primary needs for calling the tool.

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

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

Schema description coverage is 100%, so the sole parameter collection_id is fully documented in the input schema. The description adds no additional parameter-level semantics beyond the schema, which is acceptable baseline when the schema alreadx covers everything.

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

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

The description uses a specific verb ('Scan a collection') and a specific resource ('collection') with a clear objective: 'report archive health'. It then enumerates concrete deliverables: grouping by archive_status, flagging ARCHIVING stuck >24h, and listing FAILED_TO_ARCHIVE assets. This clearly distinguishes it from the many sibling list/get tools.

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

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

The description implies this tool is for checking archive health of a collection, but it does not explicitly state when to use it versus alternatives or provide exclusions. There is no sibling archive-health tool, so context is reasonably clear, but the guidance is implicit rather than stated.

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

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It only states the export action and SRT format; it does not say whether the operation is read-only, whether existing segments/subtitles must be present, or whether the result is returned directly or as a file.

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

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

The description is a single concise, front-loaded sentence with no filler words. It is appropriately short for a one-parameter tool, though it could slightly expand on behavior without becoming wordy.

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

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

With only one documented UUID parameter and no nested fields or output schema, the description plus schema is largely usable. However, it does not explain what an 'asset segment' is or how the SRT result is returned, leaving minor but real ambiguity for an agent.

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

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

The input schema covers the single asset_id parameter at 100%, and the schema already documents it as 'The asset UUID'. The description adds no additional parameter-level meaning beyond what the schema provides.

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

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

The description states a specific verb ('Export'), a resource ('asset segments'), and the output format ('SRT subtitle format'), which is enough to distinguish it from the sibling export_segments_vtt. An agent can immediately identify what the tool produces without needing the schema.

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

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

The format label implies use when SRT subtitle output is needed, but the description does not explicitly say when to choose this over export_segments_vtt or get_segments_text, nor any prerequisites or exclusions. Guidance is therefore implied rather than explicit.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says the tool 'exports' segments as WebVTT, but does not disclose whether it returns file content, a download URL, or whether all segments are included. Side effects, permissions, and limitations are unaddressed.

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

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

One short, well-structured sentence with no filler. The verb, resource, and target format are all front-loaded, making the description easy to scan and process. Every word adds value.

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

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

For a simple single-parameter tool, the description is minimally viable: it names the operation, the resource, and the output format. However, with no annotations and no output schema, it does not explain the return shape or delivery mechanism, and it omits any mention of the closely related export_segments_srt. This leaves a few important gaps for an agent deciding whether the tool is appropriate.

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

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

The single parameter, asset_id, is fully described in the schema as 'The asset UUID' with 100% coverage. The description does not add parameter-specific detail, but the baseline of 3 applies because the schema already documents the parameter completely.

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

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

States a specific verb ('Export'), a resource ('asset segments'), and an output format ('WebVTT subtitle format'). This clearly distinguishes it from the sibling tool export_segments_srt by format, and from list_asset_segments by action. The purpose is immediately understandable.

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

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

No guidance is given on when to use this tool versus export_segments_srt, get_subtitle_webvtt, or list_asset_segments. The intended usage must be inferred from the name and format, with no explicit context or exclusion criteria.

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

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

No annotations are provided, so the description carries the full burden. The word 'Get' at least conveys that this is a read-only operation with no mutation side-effects, but the description does not disclose error handling, permission requirements, or what happens when the profile is not found. For a simple getter this is minimally acceptable but not rich.

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

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

The description is a single, short sentence with no filler words. The core action and resource are front-loaded, making it easy to scan and understand instantly.

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

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

With only one required parameter and no output schema, the description is minimally sufficient for an agent to know it needs a profile_id. However, there is no detail about what the returned 'details' include, no error behavior, and no reference to the obvious sibling list_analysis_profiles, so the context is thin.

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

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

The input schema already fully describes the only parameter (profile_id) with type, format, and description, giving 100% schema description coverage. The description adds no additional parameter-level context, so the baseline schema-driven score of 3 applies.

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

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

The description states a specific verb ('Get') and a clear resource ('details of a specific analysis profile'), and the word 'specific' signals single-item retrieval, distinguishing it from list_analysis_profiles. This is unambiguous for an agent selecting between getter and list tools.

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

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

The description gives no guidance on when to use this tool versus alternatives such as list_analysis_profiles. There is no mention of prerequisites, exclusions, or the intended lookup workflow, so the agent must infer usage from the tool 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.

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

No annotations are provided, so the description carries the full disclosure burden. 'Get' implies a read operation with no side effects, but the description does not reveal what 'detailed information' includes, whether the include_* flags materially change response size, whether auth is required, or any performance/rate-limit characteristics.

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

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

A single, front-loaded sentence with zero wasted words. It states the verb, resource, and key qualifier ('by ID') efficiently. The description earns every word it uses.

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

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

Adequate for a simple get-by-ID tool; the schema covers params and the description conveys the core operation. However, 'detailed information' is vague with no output schema to clarify the return shape, and with dozens of similar get_asset_* siblings, the lack of routing guidance leaves a real completeness gap.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters ('The asset UUID', 'Include user information', 'Include collections the asset belongs to'). The description adds nothing beyond the schema, matching the baseline of 3 for high-coverage schemas.

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

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

The description uses a specific verb ('Get') and resource ('a specific asset by ID'), clearly identifying this as the general single-asset getter. It is distinguishable from sibling tools like get_asset_version, get_asset_history, or get_asset_file because those all target specific sub-resources while this targets the asset itself, though it does not explicitly name that distinction.

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

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

No guidance is given for when to use this tool versus the many related siblings. With ~15 get_asset_* sibling tools, an agent has no way to know whether to pick this general getter or get_asset_metadata, get_asset_shares, get_asset_format, etc. No context, prerequisites, or exclusions are stated.

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

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

Without annotations, the description carries the full behavioral disclosure burden. It only states a read-oriented action ('Get'), which implies no mutation, but it does not mention required permissions, what happens for missing or non-approved assets, or any response behavior.

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

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

The description is a single, direct sentence with no filler or redundant detail. It front-loads the verb and resource and is appropriately concise for a one-parameter read tool.

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

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

For a simple getter with one fully described parameter, the description is serviceable. However, there is no output schema and no clarification about approval status semantics, possible values, or failure behavior, so some context needed for confident invocation is still missing.

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

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

The input schema already fully documents the only parameter, asset_id, with its description and UUID format, so schema coverage is 100%. The description adds no additional meaning beyond 'the asset' and therefore meets the baseline but does not exceed it.

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

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

The description names a specific operation ('Get'), a specific resource ('approval status'), and a specific target ('an asset'). It clearly distinguishes this from general asset retrieval tools like get_asset by focusing on approval status specifically.

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

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

No guidance is given on when to use this tool versus alternatives. An agent cannot tell whether this is the right tool for checking an overall approval workflow, or whether another asset-related read endpoint would be more appropriate. No exclusions or alternative tool references are provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get details' implies a non-mutating read operation, but it does not state what is returned, whether content is downloaded, what errors occur, or any other behavioral traits. The description adds little beyond what the tool name already conveys.

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

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

The description is a single, front-loaded sentence with no unnecessary words or repetition. Every word contributes to the core message, making it maximally concise, even if the content is thin.

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

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

There is no output schema, so the description should clarify what 'details' means, and it does not. Given the large set of sibling tools, the description lacks the contextual information needed for an agent to know precisely what this tool returns or how it differs from other file-related getters. The simple name and parameters partially compensate, but overall the definition is incomplete.

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

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

Schema description coverage is 100%, with both parameters documented as UUIDs. The description itself adds no parameter-level meaning beyond confirming that a specific file is being fetched. Baseline 3 is appropriate because the schema handles parameter documentation.

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

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

The description states a specific verb ('Get') and resource ('details of a specific file'), which clearly indicates a read operation on a single file. However, 'details' is generic and could apply to several sibling tools like get_file_mediainfo or get_file_download_url, so it does not fully differentiate the tool's exact purpose.

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

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

The description gives no guidance on when to use this tool instead of alternatives such as list_asset_files, get_file_mediainfo, or get_asset_file_set_details. The only implied context comes from the parameter names (asset_id, file_id) in the schema, not from the description.

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

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

With no annotations, the description carries the full burden of explaining behavior. It only says 'Get details', which conveys a read-like operation through the verb, but it does not describe what is returned, possible errors, or any side effects. This leaves key behavioral aspects implicit.

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

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

The description is a single, front-loaded sentence with no filler or redundant content. Every word contributes to the core meaning, making it concise and easy to parse.

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

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

There is no output schema, no annotations, and no clarification distinguishing this tool from the near-identical sibling get_asset_file_set_details. The term 'details' is vague, so an agent cannot infer what fields are returned or how this tool differs from related list/file-set tools.

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

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

Schema description coverage is 100%, so the schema already documents both parameters at a basic level. The description adds no extra meaning about how asset_id and file_set_id relate, which IDs are expected, or any constraints beyond the schema's UUID format.

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

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

The description states a clear action and resource: 'Get details of a specific file set'. However, it does not distinguish this tool from the sibling get_asset_file_set_details, which likely serves the same purpose, so an agent cannot differentiate them from the description alone.

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

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

No guidance is provided on when to use this tool instead of list_asset_file_sets, get_asset_file_set_details, or list_file_set_files. The word 'specific' weakly implies a single-item lookup, but no conditions, prerequisites, or alternatives are mentioned.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It hints at aggregation ('combined view') but does not state whether results are paginated, how deep the file records are nested, whether storage names are resolved/enriched, or what happens for an unknown asset_id. For an aggregation endpoint, response size and shape are material and undisclosed.

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

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

A single sentence that earns each word: 'combined view' signals aggregation, 'all file sets' sets scope, and 'storage names and file records' states the returned content. Front-loaded verb and resource, zero filler.

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

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

With no output schema and no annotations, the description must convey what the caller receives and any caveats. It states the high-level contents but not the response structure, pagination, or why it is preferred over siblings. For a one-param tool the input side is simple, but the output side is under-specified for an aggregation endpoint.

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

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

Schema description coverage is 100% — the schema already documents asset_id as 'The asset UUID' with format and pattern constraints. The description adds no parameter-level detail beyond loosely tying asset_id to the asset being queried, so the baseline of 3 applies.

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

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

The description uses a clear verb ('Get') and names a specific resource: a 'combined view of all file sets for an asset with storage names and file records.' The content detail (storage names, file records) and 'combined view' phrasing distinguish it from siblings like list_asset_file_sets or get_asset_file_set, though it never names the contrast explicitly.

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

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

There is no guidance on when to call this tool versus the many closely related siblings (list_asset_file_sets, get_asset_file_set, list_file_set_files, list_asset_files). With such a dense sibling cluster, the absence of any when-to-use or when-not-to-use direction leaves the agent to guess whether it needs the aggregated view or a simple list.

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

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

With no annotations, the description is the sole source of behavioral information. It implies a read operation ('Get') but does not disclose the return format, authentication requirements, error behavior, or whether the format belongs to a specific asset context. It 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.

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

The description is a single, succinct sentence with no filler or repetition. However, 'details' is under-specified, so the brevity sacrifices some informational value.

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

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

For a simple two-parameter read operation with full schema coverage, the description is minimally adequate. But it lacks return-value details and fails to distinguish itself from closely related sibling tools, leaving an agent without enough context for confident selection.

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

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

Schema description coverage is 100%, with both asset_id and format_id described as UUIDs. The tool description adds no additional parameter semantics, so the baseline of 3 applies.

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

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

The description uses a clear verb ('Get') and resource ('format') with 'specific' indicating a single-item lookup. However, 'details' is vague and the description does not differentiate this from sibling tools like list_asset_formats or get_asset_file_set_details.

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

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

No guidance is given about when to use this tool versus alternatives such as list_asset_formats or get_asset_proxy. The description provides no context about prerequisites, intended workflow, or cases where a different tool should be chosen.

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

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

The verb 'Get' and noun 'history/audit log' imply a read-only operation with no side effects, which is helpful given no annotations are provided. However, the description does not disclose ordering, event scope, pagination behavior, or permission requirements, so it only partially carries the behavioral transparency burden.

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

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

The description is a single concise sentence with no filler. It front-loads the action and resource, making it easy for an agent to parse quickly.

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

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

For a simple paginated read tool, the description covers the core action and object, and the schema covers parameters. But with no annotations or output schema, the description could usefully clarify what kinds of events appear in the audit log and the default ordering; without that, it is minimally viable rather than complete.

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

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

Schema description coverage is 100%, with asset_id, page, and per_page already described in the schema. The description adds only minimal context by identifying the asset as the subject of the history request, so it neither improves nor harms parameter understanding.

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

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

The description states a specific verb ('Get') and a specific resource ('history/audit log for an asset'), which clearly distinguishes it from sibling tools like get_asset or list_asset_versions. The term 'audit log' conveys a distinct concept from version lists or metadata views.

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

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

No guidance is given about when to use this tool versus alternatives such as list_asset_versions or get_asset. An agent must infer usage solely from the tool name and the one-line description, with no exclusions or alternative routing.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it reveals nothing beyond the operation itself: no return format, no error behavior, no authentication requirements, and no side effects. For a data-retrieval call, safety can be assumed from the verb 'Get', but the meaning of 'details' is left entirely unspecified.

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

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

A single, front-loaded sentence with no filler: the verb and resource appear first and the sentence contains zero wasted words. The brevity is structurally clean, though it is achieved at the cost of behavioral content assessed elsewhere.

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

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

There is no output schema and no annotations, so the description is the only source of guidance, yet it does not say what fields a keyframe detail response contains or how it differs from get_keyframe_public_url. The tool is simple and its parameters are fully documented, but an agent still cannot predict what it will receive or when to prefer it over the two overlapping keyframe siblings.

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

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

Schema description coverage is 100% — both asset_id and keyframe_id have descriptions ('The asset UUID', 'The keyframe UUID') plus format and pattern constraints. The description adds no parameter-level meaning, but per the baseline for high schema coverage, the schema already carries the load adequately.

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

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

The description states a specific verb and resource ('Get details of a specific keyframe') and implies singular retrieval via the word 'specific'. It implicitly contrasts with list_asset_keyframes (plural listing) and get_keyframe_public_url (URL retrieval vs details), though it never names those siblings or enumerates what 'details' includes.

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

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

There is no guidance on when to call this tool versus the closely related siblings list_asset_keyframes or get_keyframe_public_url. No exclusions, prerequisites, or alternative-selection hints are given; an agent must infer the intended usage purely from naming conventions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read operation and that it returns all metadata views/values, but it does not disclose response shape, pagination, possible size implications, or any relationship to the narrower get_asset_metadata_view. It is not misleading, but it is thin.

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

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

The description is a single sentence with no filler, front-loading the verb and the object being returned. Every word contributes to the core purpose.

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

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

The tool is a simple one-asset read operation with a single required parameter, and the description conveys the essential purpose. However, with no output schema or annotations, the phrase 'metadata views and values' is left undefined, and there is no indication of what an agent should expect in the result, so some context is missing.

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

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

Schema coverage is 100%, so the sole parameter is already documented with its type, format, and description. The tool description adds nothing beyond the phrase 'for an asset,' which aligns with the existing asset_id description; this meets the baseline for high schema coverage.

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

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

The desc. states a clear verb ('Get') and resource ('all metadata views and values for an asset'), so it is specific enough to identify the operation. It does not explicitly contrast with siblings like get_asset_metadata_view, but the 'all views' wording hints at a broader scope than a single view.

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

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

No guidance is given on when to use this tool instead of related metadata tools such as get_asset_metadata_view, list_metadata_views, or get_collection_metadata. The context is implied but not stated, and there are no exclusions or alternatives.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates a read action and gives no information about return format, scope, side effects, errors, or prerequisites. The only implicit behavioral signal is that 'get' suggests a non-mutating operation.

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

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

The description is one short sentence with no wasted words, but it is underspecified rather than appropriately informative. It omits the key distinction between an asset metadata view and a generic metadata view, so the brevity comes at the cost of clarity.

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

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

The tool has only two simple UUID parameters and no output schema, so a short description could suffice. But the description does not clarify what 'view' means, why both asset_id and view_id are needed, or how this relates to closely named sibling tools. This is incomplete for reliable agent selection.

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

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

The input schema describes both parameters with UUID descriptions and 100% coverage, so the schema already handles parameter semantics. The description adds no meaning about how asset_id and view_id relate, but it does not need to compensate heavily given the schema coverage.

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

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

The description names a specific action and resource: 'Get metadata for a specific view.' However, 'view' is ambiguous, and the description does not clarify that this is an asset-scoped metadata view, nor does it distinguish the tool from siblings like get_metadata_view or get_asset_metadata.

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

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

There is no guidance about when to use this tool instead of alternatives such as get_metadata_view, get_asset_metadata, or list_metadata_views. The description leaves the selection decision entirely to inference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get details' implies a read operation, but nothing is said about the response shape, scoping by asset, authentication requirements, or error behavior.

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

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

The description is a single concise sentence with no filler. The core action and object are front-loaded, making it easy to scan and understand.

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

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

For a simple two-parameter getter, this is minimally viable. However, with no output schema and no annotations, the agent is left without knowledge of the return format or the relationship between the asset and proxy, and the sibling list suggests more specific proxy tools exist.

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

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

Schema description coverage is 100%, with both asset_id and proxy_id clearly described as UUIDs. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a clear verb and object: 'Get details' of 'a specific proxy'. It minimally distinguishes itself from list_asset_proxies, but does not differentiate from other proxy-related getters like get_proxy_download_url or get_proxy_public_url.

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

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

No guidance is given on when to use this tool versus alternatives such as list_asset_proxies or the URL-returning proxy tools. The intended workflow and prerequisites are left entirely to inference.

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

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

With no annotations, the description must carry the behavioral burden. 'Get' implies read-only behavior, but it does not disclose return shape, error/not-found behavior, or the role of asset_id in the lookup. Minimal behavioral transparency beyond the verb.

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

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

The description is a single eight-word sentence with no filler or repetition; the core action and selector are front-loaded. Nothing can be trimmed without losing meaning.

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

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

For a simple getter with two clearly required UUID parameters, the one-liner is arguably adequate: an agent knows the operation and the inputs. However, with no annotations or output schema, it does not fully explain return value expectations or why both UUIDs are needed, leaving it at the minimum viable level.

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

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

Schema coverage is 100%, with both params described as UUIDs, so the baseline applies. The description adds no parameter-level meaning beyond the schema and does not clarify how asset_id and segment_id relate.

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

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

The description uses a specific verb ('Get') and resource ('specific segment'), and the qualifier 'specific' distinguishes it from list-style siblings like list_asset_segments. It does not mention the asset_id context or explicitly differentiate from search_segments, so it stops short of a 5.

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

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

'By ID' implies this tool is for retrieving one known segment rather than listing or searching, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative. The usage context is only implied.

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

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

No annotations are provided, so the description alone must disclose behavioral context. It only restates the operation with scope; it does not mention pagination, whether inherited/effective shares are included, required permissions, or response shape. Nothing contradicts the read-only implication, but the burden is largely unmet.

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

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

A single, front-loaded sentence with no filler or redundant qualification. Every word earns its place.

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

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

For a one-parameter list operation the description is minimally sufficient, but without annotations or an output schema it leaves implicit details such as result format and the boundary of 'all shares' (direct vs inherited). It would benefit from one clarifying clause.

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

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

Schema description coverage is 100%: asset_id is fully documented as 'The asset UUID'. The description adds only the contextual idea of 'specific asset', so it meets the baseline but does not enrich parameter meaning.

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

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

Description states a clear verb ('Get'), a precise resource ('shares'), and a scoping qualifier ('for a specific asset'). It is readily distinguishable from sibling tools like list_shares (global) and get_collection_shares (collection-scoped).

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

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

The phrase 'for a specific asset' gives clear selection context: use when you need all shares belonging to one asset. It does not explicitly name alternatives or when-not-to-use conditions, so it misses the top score.

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

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

There are no annotations, so the description carries the full burden of disclosing behavior. 'Get' implies a read operation, but the description does not mention return shape, error behavior, permissions, or any operational characteristics. For an un-annotated tool, 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.

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

The description is a single, direct sentence with no filler. The action and target are immediately clear and front-loaded.

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

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

With no annotations and no output schema, the description would need to provide more context about what 'details' means and what kind of version data can be expected. It also does not clarify how this differs from get_asset or list_asset_versions, leaving the agent with only a shallow idea of the tool's purpose.

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

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

Schema description coverage is 100%, and both parameters have descriptions as UUIDs. The description itself adds no additional parameter semantics, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Get') and resource ('asset version'), and the word 'specific' signals this is a targeted fetch rather than a list operation. It is clear enough to distinguish from list_asset_versions, though 'details' is generic and does not explain what fields are returned.

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

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

The description implies usage when an agent has both asset_id and version_id and needs details for one version, but it does not explicitly state when to use this tool versus alternatives like get_asset or list_asset_versions. No when-not guidance or sibling routing is provided.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only restates the read-style operation by saying 'get' and gives the vague promise of 'detailed information'; it does not disclose what fields are returned, how errors are reported, or any side effects. This is a thin description for a tool with no output schema.

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

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

The description is a single, front-loaded sentence with no wasted words. It states the resource and the level of detail in a compact way.

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

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

With no output schema and no annotations, the description alone must tell the agent what 'detailed information' entails, but it does not. Given the large set of sibling collection tools, an agent cannot confidently know whether this returns metadata, contents, ancestors, or some other shape. The tool is simple, but the ambiguity makes it incomplete.

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

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

The schema covers the single parameter well: collection_id has type, format, pattern, and description. The tool description adds no meaningful parameter semantics beyond selecting a specific collection, so the baseline 3 applies when the schema already documents everything.

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

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

The description identifies a clear verb ('Get'), a resource (collection), and a specific target (a specific collection), so the agent knows this is a detail-fetch tool rather than a list tool. However, 'detailed information' is vague and does not distinguish this from the many collection-related getters (e.g., get_collection_contents, get_collection_metadata) among the siblings.

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

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

There is no guidance about when to use this tool versus alternatives such as get_collection_contents, get_collection_ancestors, or list_collections. The only usage signal is the natural implication that you need details on a specific collection, but no explicit when/when-not or alternative routing is provided.

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

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

With no annotations, the description carries the behavioral disclosure burden. It conveys that the result includes all ancestor collections, not just the immediate parent, and that they form a parent hierarchy. It does not disclose ordering, whether the collection itself is included, or the exact response shape, but for a read-only traversal this is a reasonable minimal disclosure.

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

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

One short, front-loaded sentence says exactly what the tool returns without extraneous phrasing. The parenthetical adds just enough scoping context.

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

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

For a single-parameter, low-complexity read operation with a fully described schema, the description gives an adequate idea of the result domain. It does not detail ordering or return formatting, and there is no output schema to fill that gap, but the missing details are unlikely to prevent correct selection or invocation.

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

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

Schema coverage is 100% and the only parameter is documented as 'The collection UUID'. The description adds no extra parameter semantics, so it stays at the baseline; no compensation is needed because the schema already explains the parameter fully.

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

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

The description uses a specific verb ('Get'), a clear resource ('ancestor collections'), and scopes it with 'all' and '(parent hierarchy)'. This distinguishes it from sibling tools like get_collection_subcollections, though it stops short of explicitly naming alternatives or contrasting behaviors.

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

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

The intended use is implied: call it when you need the complete ancestor chain of a collection. However, it does not state when to prefer it over similar hierarchy tools such as get_collection_full_path or get_collection_subcollections, nor does it mention any exclusions.

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

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

No annotations are provided, so the description must carry the full behavioral disclosure burden. It only says 'Get', which weakly implies a read operation, but it does not mention pagination behavior, response structure, filtering effects, or any side effects. This leaves the agent with limited understanding of how the tool behaves beyond the basic operation.

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

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

The description is a single, efficient sentence with no redundant wording. It front-loads the core purpose and adds the clarifying parenthetical in a compact way.

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

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

For a simple read-only listing tool, the schema provides most required parameter context, and the description identifies the response categories. However, with no output schema and no annotations, the description omits useful details such as pagination defaults and what fields are returned for each asset or sub-collection. It is adequate but not fully complete.

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

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

Schema description coverage is 50%, with collection_id and content_types described in the schema. The description adds meaning by explaining that contents are 'assets and sub-collections', which aligns with the content_types enum values, but it does not clarify pagination defaults or the meaning of page/per_page beyond what the schema already shows.

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

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

The description clearly states the operation: 'Get the contents (assets and sub-collections) of a collection.' It names the specific resource and scope, and the parenthetical distinguishes it from sibling tools like get_collection_subcollections, which only handles sub-collections. An agent can readily understand what this tool does.

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

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

The description implies the tool is used when you need both assets and sub-collections within a collection, but it does not explicitly state when to prefer it over list_assets, get_collection_subcollections, or get_collection. No exclusion criteria or alternative routing is provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the operation itself; it does not say whether the returned path is root-to-leaf or leaf-to-root, whether the collection itself or the root is included, how the sentinel UUIDs (zero and all-F patterns in the schema) are treated, or what happens for a nonexistent collection. 'Get' implies read-only, but that is name-level inference, not disclosure.

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

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

A single short sentence that is front-loaded with verb and resource, with the parenthetical rapidly clarifying the meaning of 'full path'. No wasted words; it is terse to the point of under-serving other dimensions, but for conciseness alone it is efficient.

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

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

With no output schema and no annotations, the description should cover the return-value contract and edge-case behavior, and it covers neither. '(breadcrumb)' hints at an ordered ancestor list, but an agent has no way to know the response shape (names, IDs, or full objects), whether the path includes the collection itself or the root, or how the special sentinel UUIDs behave. For a one-parameter tool this is close, but it falls short of what a calling agent needs.

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

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

Schema description coverage is 100%, so the baseline is 3: collection_id is already documented as 'The collection UUID' with format and pattern constraints. The description adds nothing about the parameter, which is acceptable given the schema's complete coverage.

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

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

The description uses a specific verb ('Get'), resource ('collection'), and scope ('full path'), with the parenthetical '(breadcrumb)' clarifying the hierarchy concept. It is clear in isolation but does not distinguish itself from the very similar sibling get_collection_ancestors, which covers overlapping conceptual territory.

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

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

There is no guidance about when to use this tool versus its siblings. No exclusions, no alternatives named, and no context — an agent cannot tell from the description whether to choose this over get_collection_ancestors or get_collection_contents.

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

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

With no annotations provided, the description must carry the behavioral disclosure burden. It conveys that the tool is a read operation returning metadata views and values, but it does not explain what 'all metadata views' means structurally, whether results are paginated, or how much data to expect.

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

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

The description is a single, front-loaded sentence with no wasted words. It communicates the core purpose efficiently and is appropriately sized for a tool with one parameter.

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

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

The tool is simple with one required parameter, but there is no output schema and no annotation context. The description gives the basic idea of returning metadata views and values, yet it does not clarify the return shape or how this tool relates to other metadata-focused siblings.

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

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

The schema already documents collection_id at 100% coverage, so the baseline is 3. The description does not add any further meaning to the parameter beyond implying that the collection is selected by ID, which is already obvious from the schema.

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

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

The description clearly states the action ('Get') and the resource ('all metadata views and values for a collection'), making the tool's purpose understandable. It does not explicitly differentiate from siblings like get_metadata_view or list_metadata_views, 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.

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

The description provides no guidance on when to choose this tool over related tools such as get_metadata_view, list_metadata_views, or search_by_metadata. There are no usage conditions, exclusions, or alternatives mentioned.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It indicates a read operation but does not mention required permissions, whether shares include users, groups, or URLs, or whether any filtering or pagination applies. The agent is left to infer the operational context.

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

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

The description is a single short sentence with no filler. It front-loads the action and object clearly. For a tool with one required parameter, this length is appropriate and every word earns its place.

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

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

Given no output schema and no annotations, the description is too sparse to fully equip an agent. It does not describe what a share record contains, how results are returned, or how this relates to sibling tools like list_shares or get_share. The low complexity of the input does not compensate for the missing return-value and domain context.

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

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

The input schema already documents collection_id as 'The collection UUID' with full format constraints, and schema coverage is 100%. The description adds no parameter-specific meaning beyond echoing the idea of a specific collection, which is the expected baseline for high schema coverage.

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

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

The description uses a specific verb 'Get' and a clear resource 'shares for a specific collection'. This distinguishes it from nearby siblings like get_asset_shares, which target assets rather than collections, and list_shares, which is not scoped to a specific collection.

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

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

The description offers no explicit guidance about when to use this tool versus alternatives such as list_shares or get_asset_shares. The phrase 'for a specific collection' implies a scoping condition, but it does not state what separates this tool from closely related share-related tools.

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

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

There are no annotations, so the description carries the disclosure burden. It clearly indicates a read-only aggregate retrieval, but it does not specify units, whether the size is recursive across subcollections, or whether it includes only directly contained files. This is acceptable for a simple getter but 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.

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

The description is one clear sentence with no filler or repetition. The core operation and target object are front-loaded in the same phrase.

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

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

For a one-parameter read-only tool, the description conveys the essential purpose, but it omits the output form and units, and with no output schema the agent must infer that a numeric size is returned. It is adequate but has clear gaps around return value and edge cases.

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

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

The input schema fully documents collection_id as a UUID, and the description does not need to add parameter syntax. It adds no extra meaning beyond the schema, so the baseline of 3 applies.

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

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

The description names a specific verb and resource: it returns the total size of files within a collection. This distinguishes it from sibling tools like get_collection_contents or get_asset_file, which list or retrieve individual entries rather than an aggregate.

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

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

The wording implies the tool is for obtaining an aggregate file-size figure for a collection, but it does not explicitly state when to choose it over alternatives or when not to use it. There is no mention of other tools or exclusions.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It adds only the 'direct child' scoping and does not mention read-only behavior, response format, pagination, permissions, or error semantics. This is too thin for an unannotated tool.

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

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

The description is a concise, front-loaded phrase with no filler or redundancy. Every word contributes meaning, and it is far more scannable than a longer, repetitive explanation.

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

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

The tool is simple, with one required parameter and no output schema, so the bar is lower. However, because there are no annotations, the description alone must convey enough to use the tool correctly; it stops at the operation and scope without describing the return shape, pagination, or hierarchy depth guarantees, leaving notable gaps.

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

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

The input schema has 100% coverage for the single parameter, including its UUID format and a basic description ('The collection UUID'). The description adds no parameter-specific meaning, but the schema already handles this adequately, so baseline 3 is appropriate.

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

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

The description clearly identifies the verb ('Get') and the exact resource ('direct child sub-collections'), which is a specific and meaningful scope. This distinguishes it from related siblings like get_collection_ancestors and get_collection_full_path, which handle different hierarchy relationships.

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

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

The phrase 'direct child sub-collections' implies when this tool should be used—when only immediate children are needed—but there is no explicit when-to-use or when-not-to-use guidance. No alternative tools are named or excluded, so the routing is left to inference.

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

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

The description is semantically transparent for a simple read operation: 'Get' implies no side effects, and 'currently authenticated' ties the behavior to the caller's auth session. However, it does not disclose return shape, possible authentication errors, or other runtime behavior, and there are no annotations to fill that gap.

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

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

A single front-loaded sentence with no filler, redundancy, or irrelevant detail. It earns its place and is as concise as possible for an MCP description.

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

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

For a zero-parameter, no-option read operation, the description is nearly complete: it identifies the resource and the authentication scope, which is sufficient for selection and invocation. The main gap is the lack of any return-value description, but the low complexity and absence of configuration reduce the need.

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

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

The input schema is an empty object with zero parameters, so there are no parameter semantics for the description to clarify. The 0-parameter baseline of 4 applies; no additional parameter documentation is needed.

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

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

States an unambiguous verb ('Get'), a specific resource ('user'), and a scope qualifier ('currently authenticated') that clearly differentiates it from sibling tools such as get_user and list_users. There is no ambiguity about what this tool does.

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

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

The description does not explicitly indicate when to use this tool over alternatives like get_user or list_users, and it names no exclusions or decision rules. The phrase 'currently authenticated' implies session context, but that is left to inference.

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

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

There are no annotations, so the description must carry the burden of behavioral disclosure. It only says 'Get details', which is a minimal restatement of the tool name; it does not mention permissions, error behavior, response shape, or whether the operation is read-only.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the tool's basic purpose.

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

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

This is a low-complexity tool with one required parameter and no output schema, so the description does not need to be extensive. However, with no annotations and no output schema, the vague phrase 'details' leaves the agent without a clear expectation of what the response will contain or how to handle invalid IDs.

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

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

The schema covers 100% of the parameter documentation, including the format and description of export_location_id. The description adds no additional parameter semantics beyond 'specific', 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.

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

The description states a clear verb ('Get') and resource ('specific export location'), making the operation understandable. It is distinguishable from the sibling list_export_locations by the word 'specific', though it does not explicitly name that sibling.

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

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

No guidance is given about when to use this tool versus list_export_locations or other export-related tools. The only implicit signal is the word 'specific', which suggests the caller already has an export_location_id, but no explicit condition or alternative is described.

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

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

No annotations are present, so the description carries the behavioral burden. It discloses the key trait that the URL is temporary and points to the original file, implying a read-only, expiring URL. But it omits details such as URL expiration length, authentication requirements, or failure cases.

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

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

The description is a single sentence with no wasted words. It front-loads the action and resource, and every remaining word adds meaning.

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

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

Adequate for a simple two-parameter URL fetch tool, but incomplete for an unannotated tool with no output schema. It lacks explicit alternative routing, expiry behavior, and any indication of what the caller should do with the returned URL.

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

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

Schema coverage is 100%, and both parameters are described as UUIDs in the schema. The description adds no per-parameter detail, though 'original file' clarifies why both asset_id and file_id are relevant to obtaining the original-file URL.

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

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

The description states a specific action ('Get'), a specific resource ('temporary download URL'), and the subject ('original file'). The qualifier 'original file' helps distinguish it from sibling tools like get_proxy_download_url and get_keyframe_public_url.

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

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

Usage context is implied by 'original file': an agent can infer this is for original files rather than proxies or keyframes. However, it does not explicitly name alternatives or state when not to use this tool, so routing guidance is largely left to inference.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get' clearly signals a read-only operation, which covers the primary safety trait. However, it adds nothing about prerequisites (e.g., whether the file must belong to the asset), error behavior, or return characteristics. 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.

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

A single efficient sentence with zero filler; the verb and target are front-loaded. It is appropriately short for a simple getter, though it borders on under-specification rather than intentional economy.

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

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

The tool is simple (2 required params, no enums, no nesting, no annotations, no output schema). The description is adequate for basic invocation, but gaps remain: no output schema means the agent doesn't know the shape of 'mediainfo' results, and the asset_id/file_id relationship is unexplained. Adequate for a low-complexity getter, but not complete.

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

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

Schema description coverage is 100%, so both parameters (asset_id, file_id) are already documented as UUIDs in the schema. The description adds no extra meaning beyond the schema, and importantly does not clarify the relationship between the two required IDs (that the file belongs to the asset). Baseline 3 applies because the schema does the heavy lifting.

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

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

The description states a specific verb ('Get') and a specific resource ('file') with the kind of data returned ('mediainfo/technical metadata'). This distinguishes it from nearby siblings like get_asset_file and get_file_download_url, though it doesn't explicitly name them. The qualifier 'technical metadata' is clear enough to convey the scope, if slightly vague about what exactly is included.

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

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

The description provides no guidance on when to use this tool versus the many similar file-oriented siblings (get_asset_file, get_file_download_url, get_asset_format). An agent must infer from the name that this is the go-to for technical metadata, with no explicit conditions or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals nothing beyond the operation itself — no mention of permission requirements, 404/not-found behavior, or what set of fields 'details' includes. The read-only nature is only implied by the verb 'Get'.

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

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

The description is a single efficient sentence with zero wasted words, and the action is front-loaded. However, the brevity borders on under-specification since it omits all behavioral and contextual information.

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

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

For a single-parameter tool with 100% schema coverage, invocation is adequately specified: the agent knows the group_id is required. However, with no output schema and no annotations, the description does not hint at the return shape, error behavior, or whether group membership information is included in 'details'.

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

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

Schema coverage is 100%, with group_id fully described as 'The group UUID' including format and pattern constraints. The description adds no parameter-level meaning, so the baseline score of 3 applies.

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

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

The description states a specific verb ('Get'), resource ('group'), and scope ('a specific' implying by-ID lookup). It is clear enough to distinguish from enumeration siblings like list_groups, though it does not explicitly name any alternative.

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

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

There is no guidance on when to use this tool versus related alternatives such as list_groups, list_user_groups, or get_current_user. No context, prerequisites, or exclusions are provided; the usage context must be inferred entirely from the tool name.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that details are fetched, adding nothing about behavior for nonexistent job IDs, auth requirements, or the job-status information presumably returned. For a read tool this is minimal, but not contradictory.

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

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

The single sentence has zero wasted words and front-loads the core operation. It borders on under-specification, but for a one-parameter getter the brevity is reasonable; the thinness is penalized more appropriately under contextual completeness.

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

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

There is no output schema and no annotations, so the description itself should clarify what 'details' means and what a job is in this API's context. It does neither, and fails to mention expected return fields, error behavior, or the relationship to the job-related sibling tools.

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

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

Schema description coverage is 100% — the schema already documents job_id as 'The job UUID' with format and pattern constraints. The description adds no parameter-level meaning, which matches the baseline of 3 when the schema does the documentation work.

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

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

The description 'Get details of a specific job' uses a specific verb and resource, clearly identifying a single-item fetch operation. It is distinguishable from the sibling list_jobs and list_child_jobs tools by the word 'specific', though it does not explicitly name the alternatives it is not.

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

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

No guidance is provided on when to use this tool versus alternatives like list_jobs or list_child_jobs. An agent must infer from the name that this is for fetching one known job rather than listing jobs, with no stated conditions or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a retrieval operation with 'Get', but does not disclose whether the URL expires, whether authentication is required, what the URL points to beyond the keyframe image, or how errors are surfaced.

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

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

The description is a single clear sentence with no filler or redundant detail. It is appropriately sized for a simple two-parameter retrieval tool.

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

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

The tool is simple and the input schema fully documents its two required UUIDs. However, with no output schema and no annotations, the description leaves out important context such as whether the public URL is temporary, whether it can be shared broadly, and how it differs from proxy or download URL tools.

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

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

The schema covers 100% of parameters with description for asset_id and keyframe_id. The description adds only the context that the keyframe is an image, but otherwise provides no parameter semantics beyond what the schema already states.

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

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

The description states a specific verb ('Get') and a clear resource ('a public URL for a keyframe image'). It reads naturally and conveys the tool's function, though it does not explicitly distinguish itself from the sibling get_proxy_public_url, relying on the word 'keyframe' to carry that differentiation.

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

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

There is no guidance about when to use this tool versus alternatives such as get_proxy_public_url, get_proxy_download_url, or get_asset_keyframe. The usage context is only implied by the phrase 'public URL', with no exclusions or decision criteria.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get details,' which implies a read-only operation, but it does not clarify what 'details' include, whether the field must exist, what errors may occur, or how this differs from other metadata read endpoints.

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

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

The description is a single, concise sentence with no redundant wording. It is front-loaded and appropriately sized, though the vagueness of 'details' limits its usefulness.

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

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

The tool is simple (one parameter, no nested objects), but there is no output schema and no annotations. The description should clarify what 'details' are returned and how this tool relates to similar metadata-focused tools; it does neither, leaving an agent with an incomplete picture.

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

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

The schema fully describes the only parameter, field_name ('The metadata field name'), so the description does not need to add much. It adds no extra meaning beyond what the schema already gives, which matches the baseline for high schema coverage.

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

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

The description states a clear action ('Get details') and a resource ('specific metadata field'), so an agent can tell it retrieves rather than lists or creates something. However, it does not differentiate it from siblings like get_metadata_view or list_metadata_fields, which could also return metadata field details.

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

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

There is no guidance on when to use this tool over alternatives such as get_metadata_view, get_asset_metadata, or list_metadata_fields. An agent would have to infer the appropriate context from the tool name and sibling list rather than from explicit instructions.

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

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

With no annotations, the description carries the burden of explaining behavior, and it does state that the tool retrieves details including fields, which conveys a read-oriented operation. It does not disclose potential outcomes such as not-found behavior, error cases, or whether the response contains the full view object, but for a simple getter the implied read-only behavior is reasonably clear.

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

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

The description is a single, efficient sentence that front-loads the operation and the key included detail ('including its fields'). There is no redundant or filler content.

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

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

This is a simple single-parameter retrieval tool with no output schema, and the description covers what the call returns at a useful level: details of the view and its fields. It could be more complete by noting the response form or that the view is identified by UUID, but the schema already documents the UUID parameter.

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

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

Schema coverage is 100%, and the single view_id parameter is already described as 'The metadata view UUID' in the schema. The description adds no additional semantic meaning about the parameter beyond reinforcing that the view is specific, so the schema does the heavy lifting.

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

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

The description uses a specific verb ('Get details of a specific metadata view') and identifies the resource clearly, including that the fields are part of the result. It does not explicitly distinguish itself from the similarly named sibling 'get_asset_metadata_view', which may also return fields, so some ambiguity remains for an agent choosing between them.

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

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

The description implies that this tool is used when you need details for one known metadata view, and the required view_id parameter reinforces that. However, it provides no explicit guidance about when to choose this over 'list_metadata_views' or 'get_asset_metadata_view', nor does it mention that listing first may be needed to obtain a view_id.

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

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

With no annotations, the description carries the behavioral burden. It usefully signals that the URL is temporary and that the operation is a read-like retrieval, but it does not disclose the expiration window, authentication requirements, or how the returned URL behaves. This is adequate but shallow.

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

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

A single, front-loaded sentence with no filler. Every word adds meaning: 'temporary' distinguishes the URL type, and 'proxy file' identifies the object precisely.

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

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

For a simple two-parameter tool with no output schema, the description names the return value (a temporary download URL) and the target object. Minor gaps remain around expiration specifics and how this differs from public-file URL tools, but the essentials are present.

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

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

Schema description coverage is 100%, so asset_id and proxy_id are already documented with UUID format and plain descriptions. The tool description adds no additional parameter-level meaning, which matches the baseline for high schema coverage.

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

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

The description clearly names a specific action ('Get'), a specific resource ('temporary download URL'), and a specific target ('proxy file'). It is unambiguous, but it does not explicitly differentiate this from closely related sibling tools like get_proxy_public_url or get_file_download_url.

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

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

No guidance is provided about when to use this tool instead of alternatives such as get_proxy_public_url or get_file_download_url. There are no prerequisites, exclusions, or contextual cues beyond the basic statement of what the tool does.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It indicates a read operation and conditional availability, but it does not explain what happens when a public URL is not available, whether authentication is required, whether the URL expires, 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.

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

The description is a single, focused sentence with no redundant wording. Every part earns its place, including the 'if available' qualifier that conveys conditionality.

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

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

This is a low-complexity, two-parameter retrieval tool with no output schema. The description explicitly identifies the returned artifact (a public streaming URL) and the availability condition. It does not detail error behavior, but for this simple read operation the core information an agent needs is present.

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

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

Schema coverage is 100%, with both parameters described as UUIDs for the asset and proxy. The description adds no new parameter-level detail beyond the schema, but the baseline of 3 is appropriate since the schema already documents the parameters adequately.

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

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

The description states a specific verb ('Get') and resource ('public streaming URL for a proxy'), with the caveat 'if available' adding meaningful scope. This clearly distinguishes it from the sibling get_proxy_download_url, which serves a different need.

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

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

The description implies usage when a public streaming URL is needed, and the sibling name get_proxy_download_url offers an implicit contrast. However, it does not explicitly state when to use this tool versus alternatives or mention any conditions or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does state that the tool returns all segment text content in plain text, which is useful, but it gives no information about ordering, concatenation behavior, how empty results are handled, whether timestamps are included, or any side effects/authorization requirements. For a tool with zero annotation support, this is a meaningful gap.

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

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

The description is a single, clear, front-loaded sentence with no filler. It efficiently communicates the core behavior without redundancy. Every word earns its place.

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

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

For a simple one-parameter read tool, the description mostly covers what an agent needs: the resource (segments), the operation (get all), and the output format (plain text). However, without an output schema, the description could more explicitly state whether the return value is a single string, a list, or a structured object. It also does not clarify whether 'segments' refers to transcript segments, which would be helpful given siblings like search_segments and list_asset_segments.

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

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

The input schema fully documents the only parameter, asset_id, with a format and description ('The asset UUID'). Schema description coverage is 100%, so the baseline is 3. The tool description adds no additional meaning about how asset_id influences the result, but it does not need to because the schema already covers the parameter adequately.

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

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

The description states a specific action ('Get all segment text content') and the output format ('as plain text'), making it clear that this tool returns the combined text of all segments. It is clearly distinguishable from export_segments_srt and export_segments_vtt because those produce subtitle formats while this returns plain text. However, it does not explicitly contrast itself with sibling tools such as list_asset_segments or search_segments, so a fully differentiated agent might still need to infer the distinction.

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

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

There is no guidance about when to choose this tool over alternatives such as export_segments_srt, export_segments_vtt, list_asset_segments, or get_asset_segment. The description communicates what the tool does but not the situations in which it is preferred, nor when it should be avoided. An agent is left to infer usage context entirely 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.

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

With no annotations, the description must disclose behavioral traits itself, but 'Get details' only restates the read operation. It says nothing about return contents, authentication/authorization, or whether any side effects occur.

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

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

One short sentence with no filler; the core operation is front-loaded. It is arguably under-specified but still efficiently written.

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

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

For a simple get-by-ID tool this is near the minimum viable: parameters are fully covered by the schema. But with no output schema and no annotations, the description doesn't clarify what 'details' will be returned or how this differs from get_share_url.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds no extra meaning about how share_id relates to object_type/object_id.

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

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

The description names a specific verb ('Get') and resource ('details of a specific share'), making the core operation clear. However, it doesn't distinguish this from sibling tools like get_share_url or list_shares beyond the word 'specific'.

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

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

No guidance about when to call get_share versus alternatives such as get_share_url or list_shares is provided. The description also doesn't explain that object_type and object_id scope the share lookup or any prerequisites.

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

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

With no annotations, the description carries the full burden. It implies a read-only operation via 'Get', but does not state whether an existing share is required, whether a URL is generated or just looked up, authentication expectations, or error behavior.

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

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

A single, front-loaded sentence with no filler. It communicates the core function efficiently, and every word earns its place.

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

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

For a two-parameter read-only tool, the description plus the complete schema gives a minimally viable picture. However, with no output schema or annotations, and sibling tools with similar URL-returning behavior, it leaves gaps around preconditions, return format, and tool selection.

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

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

Schema description coverage is 100%, and both parameters are already described ('The object UUID' and 'Type of shared object'). The description adds no extra meaning about the parameters, so the baseline 3 is appropriate.

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

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

States a specific verb ('Get') and resource ('public URL for a share'), which is clear. However, it does not differentiate from sibling URL-related tools like get_proxy_public_url or get_keyframe_public_url, and 'a share' is not elaborated as asset/collection beyond the schema.

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

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

No guidance is given for when to use this tool versus alternatives such as get_share, get_asset_shares, or the other public-URL tools. There are no exclusions, preconditions, or scenario descriptions.

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

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

With no annotations, the description carries the safety burden, and 'Get details' clearly signals a read-only retrieval with no side effects. It does not mention error behavior or return shape, but for a simple get-by-id tool the core behavioral trait is adequately disclosed.

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

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

The description is a single, front-loaded sentence with no filler or repetition. Every word contributes to identifying the tool's purpose.

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

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

The tool is simple, with one well-documented parameter, so a brief description is somewhat sufficient. However, with no output schema or annotations, the description leaves unclear what 'details' are returned and provides no context about error cases or related storage tools.

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

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

Schema description coverage is 100%, so the schema already documents storage_id as 'The storage UUID'. The description adds no additional meaning about how the parameter behaves or what formats are accepted, 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.

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

The description uses a clear verb ('Get') and resource ('specific storage location'), making the primary purpose obvious. It is distinguishable from list_storages because it targets a single storage unit, but it does not explicitly contrast itself with get_storage_for_purpose.

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

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

No guidance is provided about when to use this tool instead of list_storages or get_storage_for_purpose. The caller must infer from the word 'specific' and the storage_id parameter, but the description itself offers no decision support.

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

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. The verb 'find' weakly implies a read-only operation, but the description says nothing about what happens when no default storage exists for a purpose, whether authentication is required, or what the return value looks like.

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

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

A single front-loaded sentence with zero filler words. The phrasing is efficient and the key differentiating word 'default' appears early. It is not over-long, though the brevity does contribute to missing behavioral context.

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

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

The tool is low complexity: one required parameter, fully enum-constrained, no nested objects, and no output schema. The description adequately captures the operation, but there are gaps — no return format and no edge-case behavior (e.g., missing default storage) — which matter more because no output schema or annotations exist to fill them.

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

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

Schema description coverage is 100%, so the schema already documents the 'purpose' parameter with type, enum values, and a description. The description adds a small amount of meaning by linking the purpose parameter to the concept of a 'default' storage, but it does not clarify each enum value's effect.

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

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

The description uses a specific verb ('find'), a resource ('default storage'), and a scope qualifier ('for a specific purpose'), which clearly communicates what the tool does. It implicitly distinguishes itself from siblings like list_storages (all storages) and get_storage (storage by ID), though it does not explicitly name them.

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

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

There is no guidance on when to use this tool versus the closely related siblings get_storage and list_storages. The only usage cue is the description restating the function name's meaning; no exclusions, prerequisites, or alternatives are mentioned.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get subtitle content' and gives the format; it does not disclose whether the raw WebVTT text is returned directly, what structure the response takes, or any side effects or limitations.

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

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

The description is a single, concise sentence that is front-loaded with the core action and format. It is not bloated, though it is minimal.

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

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

With no output schema and no annotations, the description is too thin to fully prepare an agent to call the tool correctly. It does not clarify return structure, error behavior, or how version_id affects the result, and it does not distinguish itself among the many related sibling tools.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description adds no information about the parameters beyond what the schema provides, which matches the baseline score of 3.

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

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

The description clearly states the action ('Get') and the resource ('subtitle content') along with the output format ('WebVTT'). It is specific enough to be understood, though it does not explicitly differentiate itself from siblings like export_segments_vtt or get_transcription_subtitles.

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

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

There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, the optional version_id behavior, or how it differs from similar subtitle/segment export tools.

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

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

There are no annotations, so the description carries the burden of disclosing behavior. 'Get details' clearly indicates a read-only retrieval, but it does not mention return format, error behavior, authorization needs, or what specific fields are included. This is the minimum viable transparency for a simple getter.

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

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

The description is a single, focused sentence with no filler. The core action and target resource are front-loaded, making it easy for an agent to parse quickly.

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

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

For a simple read-by-id tool, the description and schema together are largely sufficient: the only required parameter is fully documented, and 'details' gives a reasonable sense of the return value. There is no output schema, so a note about the returned fields or behavior on missing IDs would improve completeness, but the low complexity reduces that need.

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

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

Schema description coverage is 100%, and the parameter already includes a meaningful description ('The transcoder UUID') plus format and pattern constraints. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Get') and resource ('details of a specific transcoder'), and the word 'specific' signals this is a single-object retrieval rather than a listing like the sibling list_transcoders. It is clear, though it does not explicitly name or contrast the alternative sibling.

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

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

The description implies the tool should be used when you already have a transcoder_id and need details for one transcoder, as opposed to listing all transcoders. However, there is no explicit when-to-use, when-not-to-use, or alternative routing guidance.

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

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

No annotations are present, so the description carries the full burden. It only says 'Get', implying a read operation, but does not disclose response shape, whether transcription properties can be absent, error behavior, or any access requirements.

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

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

The description is one concise sentence with the verb and resource front-loaded and no wasted phrases. It is efficient, though it leaves room for more useful context without becoming verbose.

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

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

With simple, well-documented parameters, the call is minimally viable. However, there is no output schema and no annotation, so the agent is not told what 'transcription properties' includes or what the response should look like.

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

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

The schema already describes both parameters with 100% coverage, so the baseline is 3. The description adds no extra parameter meaning beyond connecting the operation to an asset version.

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

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

The description uses a specific verb and resource ('Get transcription properties for an asset version'), so the tool's purpose is immediately understandable. It does not explicitly differentiate from siblings like get_transcription_subtitles, but the phrasing is clear enough to identify the operation.

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

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

There is no guidance on when to use this tool versus alternatives such as get_transcription_subtitles or other asset/version getters. No exclusions, prerequisites, or selection conditions are provided; the only contextual clue is 'for an asset version'.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but the description does not state what the returned subtitles look like (format, encoding, structure), whether a file is produced, or any other behavioral characteristics. The only signal is the verb.

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

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

The description is a single five-word phrase with no wasted words, front-loading the action and resource. It is concise, though it borders on being too terse to be genuinely informative.

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

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

There is no output schema and no annotations, so the description is the only source of context. It fails to explain what format the subtitles take, how they relate to the transcription, or how to choose between this tool and the many sibling tools that also produce subtitle content. This leaves an agent uncertain about the return value and tool selection.

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

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

Schema description coverage is 100%; both asset_id and version_id are documented as UUIDs. The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific action ('Get') on a resource ('transcription') and the output form ('subtitles'), which is clear and not a tautology. However, it does not distinguish this from nearby sibling tools such as get_subtitle_webvtt, export_segments_srt, and export_segments_vtt, which also involve subtitle outputs, so the differentiation is incomplete.

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

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

No guidance is provided on when to use this tool versus alternatives. The sibling list includes several tools that could plausibly return subtitle data (get_subtitle_webvtt, export_segments_srt, export_segments_vtt, list_asset_subtitles), but the description gives no selection criteria, exclusions, or context.

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

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

With no annotations provided, the description carries the full disclosure burden, but it only conveys a read intent ('Get details'). It does not mention permission requirements for viewing other users, behavior on missing or invalid IDs, or the response shape. No contradiction exists since there are no annotations to conflict with.

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

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

A single seven-word sentence with zero filler, front-loaded with the verb and resource. It is appropriately sized for a simple tool, though the brevity leaves room for a sibling-differentiation note that would have improved it.

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

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

The tool is low-complexity — one well-specified required parameter — so the description is near-sufficient, but gaps remain: there is no output schema so the agent cannot anticipate the return shape, and the overlap with get_current_user is unresolved. Adequate for a simple read, with clear gaps.

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

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

Schema description coverage is 100% — user_id is fully documented with type, UUID format, pattern, and a description ('The user UUID'). The description's phrase 'a specific user' adds only marginal confirmation of the ID-based lookup, so the baseline 3 applies with the schema doing the heavy lifting.

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

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

The description states a clear verb and resource: 'Get details of a specific user' communicates a fetch-by-ID operation. It is not a tautology — 'specific' plus the required user_id parameter makes the granularity clear — but it does not explicitly distinguish itself from the sibling get_current_user, which retrieves the calling user's own details.

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

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

No guidance on when to use this tool versus the natural alternatives in the sibling list (list_users for enumeration, get_current_user for the calling user's own profile). The agent is left to infer from the user_id parameter that this targets a known user; there is no explicit when/when-not framing or alternative routing.

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

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

No annotations are provided, so the description carries the burden. 'List all' strongly implies a read-only, unfiltered retrieval, which is a basic behavioral statement for a zero-parameter operation. However, it does not disclose response shape, pagination, ordering, or potential rate-limit behavior.

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

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

One short, front-loaded sentence with no filler. 'For media processing' adds useful domain scope without bloating the description.

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

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

For a simple parameterless list tool, the description is nearly complete: an agent knows what it lists and that no arguments are required. It omits return-value details and does not route users to get_analysis_profile for single-profile details, but the low complexity makes those omissions minor.

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

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

The tool has zero parameters, so there is no parameter semantics gap. The schema is trivially complete, and the baseline for 0-parameter tools is 4. The description does not need to add parameter-level detail.

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

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

The description uses a specific verb ('List') and a specific resource ('analysis profiles'), and the word 'all' distinguishes it from the singular get_analysis_profile sibling. It clearly conveys a read-only listing operation.

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

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

There is no guidance about when to use this tool instead of get_analysis_profile or other list_* tools. No alternatives, exclusions, or typical use cases are mentioned; the only implied context is that you list all profiles when you want an overview.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. 'List all files' clearly implies a non-destructive read operation and indicates full-result scope, but it does not mention pagination, ordering, or whether files from all versions are included. There is no contradiction with annotations because none exist.

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

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

The description is a single short sentence with no filler or redundancy. The action and resource are front-loaded, making it easy to scan and immediately understood.

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

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

For a simple list tool with fully documented parameters, the description is adequate but not complete. It does not clarify the relationship between asset files and file sets, nor does it explain the effect of the optional version_id from a behavioral standpoint. Since there is no output schema, the description also leaves the return shape entirely unspecified.

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

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

Schema description coverage is 100%, with both asset_id and version_id already described and constrained by UUID format. The description adds no parameter-specific 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.

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

The description clearly states the operation ('List') and the resource ('files associated with an asset') in a single, specific sentence. It is easily understood as a read-only listing tool, but it does not distinguish itself from closely related sibling tools like list_asset_file_sets or list_file_set_files, so it stops short of full clarity.

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

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

The description provides no guidance on when to use this tool versus alternatives such as list_asset_file_sets, list_file_set_files, or get_asset_file. It also does not mention the optional version_id filtering behavior or any exclusion criteria, so an agent must infer usage entirely from the tool name and schema.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the listing operation and adds no detail about output shape, pagination, ordering, or the effect of omitting version_id. It does at least imply a read-only operation through the verb 'List'.

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

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

A single concise sentence with no wasted words, and the core operation and scope are front-loaded. This is appropriately minimal for a straightforward list tool.

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

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

For a simple read-only list tool with a fully documented schema, this is adequate for basic invocation. However, with no annotations and no output schema, the description leaves usage guidance and behavioral context underspecified, so the agent must rely on the schema and tool name alone.

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

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

Schema description coverage is 100%, and the schema already explains asset_id and version_id, so the baseline is 3. The description adds no extra parameter meaning beyond tying the list to an asset, but the schema carries the necessary detail.

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

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

The description names a specific verb ('List'), resource ('file sets'), and scope ('for an asset'), so the core operation is clear. It does not explicitly distinguish this from get_asset_file_set or list_file_set_files, but the phrase 'all file sets' makes its role as the list operation apparent.

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

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

No guidance is given on when to use this tool instead of get_asset_file_set_details or list_file_set_files, nor on how the optional version_id should affect the choice. The intended usage is only implied by the tool name and one-line description.

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

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

Because no annotations are provided, the description bears the burden of indicating behavior. It clearly implies a read-only listing operation and gives example values, but it does not disclose return shape, possible errors, pagination, or authentication requirements. The description is not misleading but adds only limited 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.

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

The description is a single, efficient sentence with no redundant words. It leads with the action and the examples are parenthetically useful. Every part contributes value.

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

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

For a simple list tool with two well-documented parameters and no output schema, the description is sufficient to let an agent understand the basic purpose. No return value explanation is required since there is no output schema. A minor gap is the absence of any mention of the optional version_id filter in the description, but the schema covers it.

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

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

Schema description coverage is 100%: both asset_id and version_id have meaningful descriptions, including that version_id is an optional filter. The tool description adds little beyond the schema, merely restating the asset context for formats. Baseline of 3 applies because the schema already documents the parameters adequately.

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

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

The description states a clear action ('List') and a specific resource ('formats') with concrete examples ('ORIGINAL, PROXY, etc.'). This makes the tool's purpose unambiguous and distinguishes it from siblings like get_asset_format or list_asset_versions.

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

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

The description gives no guidance on when to prefer this tool over alternatives such as list_asset_proxies or get_asset_format, and it states no exclusions or conditions. For example, it does not mention that get_asset_format retrieves a specific format or that list_asset_proxies focuses on proxies only.

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

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

There are no annotations, so the description is the only signal about side effects. 'List all...' clearly indicates a read-only enumeration, which is useful, but it omits pagination, ordering, return shape, and any auth nuance. The behavior is not misleading, just underspecified.

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

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

One short sentence with the verb and object front-loaded. Every word earns its place; there is no filler, repetition, or restating of the schema.

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

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

With only two parameters and one required, the schema plus the description give enough to make a correct call: asset_id identifies the asset, and version_id is optional. The absence of an output schema means the return entry shape is not documented, but that is not necessary to invoke the tool. More detail on what a keyframe entry contains would improve completeness.

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

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

Schema description coverage is 100%: asset_id is documented as 'The asset UUID' and version_id as 'Filter by version (optional)'. The tool description adds no extra parameter semantics, so the baseline of 3 applies.

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

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

The description states a specific action ('List all') on a specific resource ('keyframes/thumbnails') scoped to an asset. This makes it easy to distinguish from the singular get_asset_keyframe and from get_keyframe_public_url, which serve different purposes.

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

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

No explicit when-to-use or when-not-to-use guidance is given. The agent must infer from sibling names that get_asset_keyframe should be used for a single keyframe, and no alternative is mentioned for version filtering.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says only that it lists proxy files; it does not disclose whether it returns metadata, whether it requires asset access permissions, whether it includes all versions, how pagination works, or what the response shape is. For a listing operation this is a meaningful gap.

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

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

A single sentence communicating the core purpose with no wasted words. It is appropriately sized for a list tool, though it lacks the behavioral detail that would make it more valuable.

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

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

The description adequately conveys the core operation and the schema covers both parameters. However, with no annotations, no output schema, and no mention of return value/pagination/permissions, an agent cannot fully anticipate the tool's behavior. For a simple list tool this is a minimum-viable definition, not a complete one.

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

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

Schema description coverage is 100%, so the schema already documents asset_id ('The asset UUID') and version_id ('Filter by version (optional)'). The description adds no parameter-specific meaning beyond what the schema states; the baseline of 3 applies because the schema carries the documentation burden.

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

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

The description "List all proxy files for an asset" clearly identifies the verb (list), resource (proxy files), and scope (for an asset). It distinguishes the tool from get_asset_proxy (singular retrieval) and from list_asset_versions/list_asset_formats, though it does not explicitly name those siblings.

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

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

The description implies usage: call when you need all proxy files associated with an asset. However, it offers no when-not-to-use guidance and does not distinguish between this tool and the closely related get_asset_proxy, list_asset_formats, or list_asset_files. An agent must infer the boundary from sibling names.

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

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

With no annotations, the description carries the behavioral burden, but it only states a read-only 'List' operation. It does not disclose pagination behavior, how the optional relation_type filter affects output, relation direction, or response shape, leaving the agent to infer important behavioral details.

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

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

The description is a single concise sentence with no filler words. It front-loads the action and object immediately, and every word contributes to understanding the tool's scope.

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

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

For a simple two-parameter list tool, the description plus the input schema is minimally viable for invoking the tool with an asset_id. However, with no output schema and no annotations, the agent still cannot anticipate the response format, pagination, or edge-case behavior, leaving meaningful gaps.

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

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

The input schema already documents both parameters: asset_id is described as 'The asset UUID' and relation_type as 'Filter by relation type'. Schema description coverage is 100%, so the description does not need to add much, but it also adds no additional semantic nuance beyond the schema.

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

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

Description uses a specific action ('List'), a specific resource ('all relations'), and a clear scope ('for an asset'), so the core purpose is unambiguous. It does not explicitly distinguish itself from siblings such as list_relation_types, but the asset-scoped phrasing prevents most confusion.

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

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

No guidance is given about when to use this tool versus alternatives, nor are there any exclusions or recommended sibling tools. The only implicit clue is that an asset_id is required, but no context about relation types or when this list is preferable is provided.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It only mentions 'with pagination' and does not state that this is a read-only operation, how results are returned, default sort/order behavior, or how pagination actually behaves beyond the schema parameters. The description adds minimal 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.

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

The description is a single front-loaded sentence with no filler: 'List all assets with pagination' conveys the core operation and the distinguishing feature efficiently.

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

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

For a simple list tool with fully documented parameters, the description is minimally adequate. However, with no output schema and no annotations, it leaves the response shape and the boundary against search_assets implicit, so a bit more context would make it complete.

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

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

Schema description coverage is 100%: page, per_page, sort, and order all have descriptions and defaults. The description adds only the pagination context and does not need to repeat parameter details, 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.

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

The description states a clear verb-resource pair ('list assets') and adds the pagination qualifier, so an agent can tell this is a paginated listing of assets rather than a single-asset retrieval. It does not explicitly contrast with sibling tools like search_assets or list_asset_versions, so it loses a point on differentiation.

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

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

There is no guidance on when to use this tool versus alternatives. With siblings like search_assets, search_faceted, and list_asset_versions, the description should indicate that this is for unfiltered, paginated listing of all assets, but it offers only the generic 'List all assets' statement.

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

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

No annotations are provided, so the description carries the full burden. It discloses the high-level listing behavior but does not mention that results are paginated via page/per_page, that a segment_type filter can narrow results, or what the response shape is. The phrase 'all segments' is also slightly misleading given pagination.

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

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

One front-loaded sentence with no filler. The verb, resource, scope, and illustrative segment types are all present in a compact, readable form.

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

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

With four parameters, no annotations, and no output schema, the description is too sparse to fully guide invocation. It does not cover pagination limits, optional filtering behavior, or how this listing relates to sibling segment tools such as get_asset_segment and search_segments.

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

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

Schema coverage is 50%, with descriptions for asset_id and segment_type but not page/per_page. The description adds useful context by listing example segment types, but it does not explain pagination defaults or how segment_type interacts with the listing. Overall, the schema and defaults carry most of the parameter meaning.

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

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

The description uses a specific verb and resource: 'List all segments... for an asset' with concrete examples of segment types. It clearly distinguishes from singular get_asset_segment and search/export segment tools by emphasizing the listing scope.

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

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

The description implies the tool is for listing segments per asset, which is clear context, but it does not explicitly state when to prefer this over alternatives like search_segments, get_asset_segment, or export_segments_srt. Usage is inferred rather than stated.

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

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

No annotations are provided, so the description carries the full disclosure burden. It only says 'List all subtitle tracks' and does not mention response shape, whether subtitle metadata includes language or format fields, or how version_id changes the result set. This is minimal for a tool with no annotation safety hints.

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

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

The description is a single sentence with no filler, front-loading the verb and resource immediately. It earns its place, though it could be expanded with minimal effort to improve usefulness.

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

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

For a straightforward list operation with a clear required parameter, the description is minimally viable. However, with no output schema and no mention of return contents or behavior relative to version_id, an agent may not know what data to expect from the response.

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

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

Schema description coverage is 100%; both asset_id and version_id are already documented in the schema. The tool description adds no further parameter context beyond the resource-level 'subtitle tracks for an asset', so baseline 3 is appropriate.

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

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

The description states a specific verb ('List') and resource ('all subtitle tracks for an asset'), making it clear what the tool returns. It does not explicitly contrast with siblings like get_subtitle_webvtt or export_segments_srt, but the 'list' framing implies metadata coverage rather than content retrieval.

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

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

The description gives no guidance on when to use this tool instead of related siblings such as list_asset_segments, get_subtitle_webvtt, or get_transcription_subtitles. An agent must infer the intended selection from the tool name alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the list operation. It doesn't disclose ordering, pagination, whether soft-deleted versions are included, or any permission requirements, so the agent cannot anticipate the tool's behavior beyond the literal action.

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

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

Six words, front-loaded with the action, with zero waste. Every word earns its place and the core purpose is readable at a glance.

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

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

For a one-parameter list operation the description is close to adequate, but with no output schema and no annotations it leaves ordering, pagination, and response shape unspecified. It also doesn't clarify the boundary with get_asset_history, which an agent could plausibly confuse for version listing.

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

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

Schema description coverage is 100% — the single asset_id parameter is fully documented in the schema with type, format, pattern, and description. The tool description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb ('List') and resource ('all versions of an asset'), making the operation unambiguous. It distinguishes from get_asset_version (singleton fetch) and other list_asset_* siblings by naming the resource, though it doesn't explicitly disambiguate against get_asset_history, which could also surface version-related information.

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

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

The description offers no guidance on when to call this tool versus alternatives like get_asset_version, get_asset_history, or the other list_asset_* tools. An agent must infer the correct choice purely from the name and resource noun, with no explicit conditions or exclusions.

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

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

With no annotations available, the description itself signals that this is a read-only, non-mutating operation by using the verb 'List', which implies a collection result. However, it does not disclose pagination behavior, response shape, or whether the listing is limited to immediate children or recursive.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to the core purpose, making it instantly scannable.

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

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

There is no output schema or annotations, and the description gives no details about pagination, returned job fields, or how child jobs relate to other job endpoints. The definition is enough to guess the call, but not enough to know what to expect from the response.

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

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

The description adds no parameter-level meaning beyond what the schema already provides. Schema description coverage is only 50%, and page and per_page remain undocumented in both the schema and the description, so the gap is not compensated for.

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

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

The description states a specific action ('List'), a specific resource ('child jobs'), and a scope ('of a parent job'), so an agent can understand what it does. It is clear enough to be distinguished from siblings like list_jobs and get_job, though it does not explicitly call out those alternatives.

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

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

There is no guidance on when to prefer this tool over siblings such as list_jobs or list_job_steps, nor any exclusions. The parent-child phrasing implies a use case, but the agent must infer selection logic entirely from context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only adds 'with pagination', which is already evident from the page and per_page parameters in the schema. It does not state scope (e.g., user-accessible collections), default ordering behavior, or whether the result is read-only.

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

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

The description is a short, front-loaded phrase with no unnecessary words. It is appropriately concise for a simple list operation, though it could have included more context without becoming bloated.

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

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

For a tool with four optional parameters fully described in the schema, the description is minimally adequate. However, it lacks any mention of output shape or access scope, and there is no output schema to compensate. The meaning of 'all collections' is ambiguous (all visible to the user vs. all in the system).

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already documents; 'with pagination' is a minor restatement of the pagination parameters.

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

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

The description uses the specific verb 'List' with a clear resource 'collections' and signals pagination behavior. It is distinct from singular collection tools like get_collection, though it does not explicitly name any sibling alternatives.

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

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

No guidance is provided about when to use this tool versus alternatives such as get_collection or get_collection_contents. The agent must infer selection solely from the name and description, with no explicit context or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It states 'List' which implies a read-only operation, but it does not disclose what the delete queue represents, whether results are paginated or ordered, whether any authentication or permissions are needed, or what the response contains. The phrase 'delete queue' is ambiguous.

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

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

The description is a single concise sentence with no redundant words. 'List file sets in the delete queue' is front-loaded 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.

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 minimally adequate, but it leaves gaps: the meaning of 'delete queue' is not explained, and there is no output schema to clarify the return structure. It is not as incomplete as a mutation tool, but it could still benefit from clarifying what 'delete queue' means and what is returned.

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

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

The tool has zero parameters and the schema is empty, so there is no parameter semantics burden for the description. Baseline for zero parameters is 4; the description does not need to add parameter details.

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

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

The description specifies a clear action ('List'), a resource ('file sets'), and a scope ('in the delete queue'). It is not a tautology and is distinguishable from sibling tools like list_asset_file_sets and list_deleted_formats, though it does not explicitly name those alternatives.

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

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

The description provides no guidance on when to use this tool versus list_asset_file_sets, list_file_set_files, or list_deleted_formats. There is no mention of prerequisites, intended use cases, or exclusions, so the agent must infer usage from the tool name alone.

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

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

With no annotations provided, the description carries the behavioral burden. The verb 'List' and the qualifier 'in the delete queue' indicate a read-only, scoped query. Still, it does not disclose details such as queue semantics, ordering, or whether listed items are recoverable, leaving some behavioral ambiguity.

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

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

The description is a single, front-loaded sentence with no wasted words. It states the operation and the exact scope efficiently.

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

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

For a zero-parameter tool, this is mostly sufficient, but the lack of an output schema and annotations means the description does not clarify what a returned format record looks like or what 'delete queue' means precisely. An agent can call the tool, but may not know the shape or semantics of the response.

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

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

The input schema has zero parameters, so there are no parameter semantics to document. The baseline of 4 applies because the description cannot add meaning to parameters that do not exist.

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

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

The description names a specific verb ('List') and a specific resource scope ('formats in the delete queue'), which clearly sets it apart from siblings like list_asset_formats or list_deleted_file_sets. An agent can immediately understand what this tool returns.

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

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

The description implies when to use it: whenever formats in the delete queue are needed. However, it does not explicitly state when not to use it or mention alternatives, so the guidance remains implicit rather than prescriptive.

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

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

The verb 'List' implies a safe, read-only operation, which is a behavioral trait. Yet with no annotations and no output schema, the description provides no details about return format, pagination, or permissions, leaving the agent to infer behavior from 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.

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

The description is a single, entirely meaningful sentence with no wasted words. It is front-loaded and appropriately sized for a zero-parameter list operation.

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

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

For a simple zero-parameter list tool with no output schema, the description is largely complete: it tells the agent what the operation returns (a list of export locations). Minor gaps like the exact shape of each location item are inferable from sibling tools such as get_export_location.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the empty schema confirms no arguments are required.

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

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

The description clearly states a specific verb ('List') and resource ('configured export locations'), and the word 'all' distinguishes it from the singular sibling get_export_location. However, it does not explicitly differentiate from other list_* tools, making it clear but not fully distinguishing.

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

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

Usage is implied by the description: an agent would use this when needing a list of all export locations. However, there is no explicit guidance on when to prefer this over alternatives like get_export_location, nor any mention of exclusions or prerequisites.

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