interchange_can_translate_source_data

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and non-open-world, so the safety profile is covered and 'Read-only' in the description is largely redundant. What the description does add is that the input may be either a path on disk or an asset path, plus the exact result shape. Since no output schema exists, disclosing the return fields (file_path, scene_only, can_translate) is genuinely additive 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?

Three short sentences, front-loaded with the core predicate and with the return shape last where it belongs. The only waste is the 'Read-only.' fragment, which duplicates the readOnlyHint annotation and does not earn 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 two-parameter read-only predicate with no output schema, the description supplies the operation, the accepted input forms, which translator types are considered, and the return fields. An agent has everything needed to call it correctly. It could be slightly stronger by noting that this is a check rather than an import and by mentioning scene_only in prose.

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 file_path and scene_only are already fully documented, including the disk-vs-asset path duality and the bSceneOnly restriction. The description only echoes the path duality and never mentions scene_only at all. Baseline 3 is appropriate when the schema carries the 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 and resource: a predicate test of whether a registered Interchange translator can read a source file. That is distinct from the mutating siblings such as interchange_import_asset or interchange_reimport_asset. It stops short of naming an alternative (e.g. interchange_get_supported_formats) or stating when this pre-check should be performed.

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 rather than stated: the description says it tests whether a translator can read a file, which strongly suggests a pre-flight check before import. However it never says when to call it, when not to, or which sibling to use instead. No explicit routing guidance against the large interchange_* sibling family.

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