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

No annotations are provided, so the description must disclose behavioral traits itself. It does not mention result format, pagination behavior, authentication needs, performance implications, or what 'advanced' means operationally. The sentence merely restates the tool's advertised capability.

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

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

The description is extremely short, but this is under-specification rather than effective conciseness. It front-loads no critical scoping information and every word adds minimal 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?

Given four parameters, no annotations, multiple sibling search tools, and zero schema description coverage, this one-sentence description is far from complete. It does not clarify the search scope, available sort fields, result limits, or relationship to sibling search tools, so an agent lacks essential context for correct invocation.

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

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

Schema description coverage is 0%, and the description does not explain any parameter semantics. It only mentions sorting and filtering generically, leaving query, sort_field, max_results, and sort_ascending without added meaning beyond their names and schema defaults.

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 verb ('search') and indicates the capability ('sorting and filtering'), but it does not state what is being searched (content, metadata, or both). It is only slightly more informative than the tool name and does not distinguish itself from sibling tools like search_content, search_by_metadata, or cmis_search.

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 advanced_search versus the several sibling search tools. There are no conditions, exclusions, or alternative recommendations, so an agent cannot determine which search tool fits a given request.

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 merely says 'browse', a weak indicator of read-only behavior, but does not explicitly state that the tool performs a read operation, what happens with an invalid parent_id, pagination behavior via max_items, or any permission requirements. This is a significant gap.

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

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

The description is extremely concise at six words, with no fluff and the verb front-loaded. However, the brevity comes at the cost of critical context. While it earns its place as a minimal statement, it is under-specified for a tool with parameters and no other documentation.

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 an output schema present, explaining return values is unnecessary. However, the description lacks guidance on parameters, usage scenarios, and behavior. For a tool with two optional params and no annotations, the description should cover basics like the default parent_id='-my-' and what 'browse' returns (e.g., child nodes). This 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 0%, meaning the input schema includes no descriptions for max_items or parent_id. The tool description does not mention these parameters at all, so it adds no semantic clarity. An agent must guess that parent_id refers to a node ID and max_items limits results, but nothing explains their meaning, defaults, or acceptable values.

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 the verb 'browse' and the resource 'Alfresco repository structure', giving a basic sense of purpose. However, it is vague about what 'browse' returns or how it relates to sibling tools like get_node_properties or search_content. It does not explicitly distinguish itself, so an agent might not know whether this lists child nodes or performs a search.

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 that browsing is for navigating the folder tree as opposed to searching, nor does it mention prerequisites like parent_id. No exclusions or alternatives are named, leaving the agent to infer usage 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?

No annotations are provided, so the description carries the full burden. It does disclose the key behavioral consequence—discarding the working copy—which is valuable. However, it does not mention reversibility, permissions, or behavior when the document is not checked out, leaving meaningful gaps for a mutating tool.

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

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

The description is a single concise sentence with no filler. The action is front-loaded, and the important consequence is included without extra words.

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 one parameter and an output schema, the description adequately covers purpose and effect. However, the absence of annotations and any prerequisite context (e.g., document must be checked out first) leaves a small 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?

The schema has 0% description coverage, but the single parameter node_id is inferable from the tool name and the phrase 'of a document'. The description does not add explicit parameter-level detail, but the minimal context is enough to guide invocation.

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 ('cancel checkout'), a specific resource ('document'), and a concrete effect ('discarding any working copy'). This clearly distinguishes it from sibling tools like checkout_document and checkin_document.

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. Sibling tools include checkout_document and checkin_document, but the description does not mention them or specify the conditions under which cancellation is appropriate.

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 mentions using the Alfresco REST API, which adds implementation context, but it does not disclose what happens to the checked-out state, whether the document is locked/unlocked, how versioning works, or what the response contains. For a mutation tool, this is a significant gap.

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

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

The description is a single concise sentence that is easy to scan and front-loads the action. It earns its place by adding the 'after editing' context and the Alfresco REST API detail, though it could be slightly more informative 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?

Given the tool has five parameters, no annotations, and an output schema, the description is too thin. It does not explain the check-in workflow (e.g., that it typically follows checkout_document), the role of file_path, or the meaning of major_version. An agent would need to inspect the schema and output schema to understand basic semantics, which the description should provide.

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 0%, so the description must compensate for the five parameters. It does not explain the meaning of node_id, comment, new_name, file_path, or major_version, nor how they interact (e.g., whether file_path is required for content updates). The description adds no parameter-level value beyond the schema's bare names.

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 ('Check in') and resource ('a document'), and the phrase 'after editing' gives the operation's context. It clearly distinguishes from siblings like checkout_document and cancel_checkout, though it doesn't 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?

The description implies the tool is used after editing a document, which is a clear usage context. However, it does not explicitly state when not to use it or mention alternatives like cancel_checkout for discarding changes, leaving some inference to the agent.

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. 'Check out' implies a state-changing mutation, but the description does not disclose that the document becomes locked/checked-out, that a follow-up checkin or cancel_checkout is required, or what effect download_for_editing has on the workflow. This is a significant gap for a 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?

A single front-loaded sentence with the action stated first; every word earns its place except the mild filler tail 'using Alfresco REST API', which adds little for an agent selecting a tool. It is concise without being under-specified to the point of tautology.

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?

Although an output schema exists (so return values need not be explained), the description omits the operational lifecycle: what checkout does to the document state, the purpose of download_for_editing, and the relationship to checkin_document/cancel_checkout. For a state-changing tool with no annotations, this leaves too much to inference.

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

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

Schema description coverage is 0%, and the description compensates with nothing. Neither node_id nor the ambiguous download_for_editing boolean is explained; 'for editing' only loosely echoes the parameter name without defining its meaning, default behavior, or why an agent would set it to false.

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 ('Check out') and resource ('a document for editing'), making the core purpose immediately clear. It semantically contrasts with the sibling tools checkin_document and cancel_checkout, though the distinction is implicit rather than named. The 'using Alfresco REST API' clause is implementation detail but does not obscure the 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 phrase 'for editing' provides clear context for when this tool is appropriate, and the sibling set implies the checkout→edit→checkin/cancel workflow. However, the description never explicitly states when to use this versus checkin_document or cancel_checkout, nor does it mention any prerequisites 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, but it only states the query language and default target. It does not explain behavior such as how max_results is applied, whether results are truncated, read-only semantics, or any side effects. The description is minimal and leaves important behavioral expectations unstated.

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 very short and front-loaded with the key mechanism ('CMIS SQL syntax') and the default behavior. It contains no filler, though the brevity leaves room for more useful guidance without harming conciseness.

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

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

Given the large set of sibling search tools, the absence of usage differentiation is a significant gap. The description also does not mention result handling, result limits, or how this search relates to other repository tools. Despite having an output schema, an agent still lacks enough context to know when this tool is the right choice.

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 0%, so the description must compensate, but it only clarifies that cmis_query uses CMIS SQL syntax and defaults to PDF documents via the schema's default value. The max_results parameter receives no explanation at all, and the description does not go beyond what the parameter name and default values already suggest.

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 ('Search') and a resource/method ('CMIS SQL syntax'), and it mentions the default query targets PDF documents. However, it does not explicitly distinguish itself from sibling search tools like search_content, advanced_search, or search_by_metadata, leaving some differentiation to inference.

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 sibling search tools. It does not mention prerequisites, use cases, or exclusions, so an agent must guess when CMIS SQL is appropriate compared to search_content, advanced_search, or search_by_metadata.

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 states only the basic effect (a folder is created) and gives no information about duplicate handling, whether parent_id is validated, required permissions, or side effects. This is minimal guidance, not meaningful transparency.

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

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

The description is a single, front-loaded sentence with no redundancy or fluff. It is concise, though it is concise at the expense of completeness—a tradeoff reflected in the other dimension scores.

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?

Having an output schema helps with return-value understanding, but the description still omits critical context: how parent_id works, the meaning of the default, whether the folder is created in a shared location, and what errors or conflicts may occur. For a mutating tool with no annotations, this is not complete enough for confident invocation.

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

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

Schema description coverage is 0%, and the description does not explain any parameter. In particular, parent_id defaults to '-shared-' but its meaning is never clarified, so an agent cannot reliably know whether it expects a node ID, a path, or a folder name.

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 the action and resource: creating a new folder in Alfresco. This is enough to distinguish it from sibling tools like upload_document or delete_node, though it does not provide any detail about location or scope beyond 'Alfresco'.

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, or about prerequisites such as authentication, parent folder ownership, or permissions. The only cue is the tool name, which does the work the description should be doing.

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 states the action (delete) but does not disclose consequences such as whether deletion is reversible, what happens to children of a folder, whether the 'permanent' parameter bypasses trash, or any authorization requirements. The description adds minimal behavioral context beyond the tool 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, short sentence that is easy to parse and front-loads the core action. It is appropriately concise, though it could add a second sentence about the 'permanent' parameter 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?

Given the tool has an output schema and only two parameters, the description is too thin. It lacks critical context about deletion semantics (permanent vs. trash), folder behavior, and any side effects. The output schema exists but the description does not explain what the response contains or when the operation fails. For a destructive operation with no annotations, this is a significant 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 0%, and the description does not explain the parameters. The schema shows 'node_id' (string) and 'permanent' (boolean, default false), but the description does not clarify what 'permanent' means (e.g., bypass trash vs. trashable) or how node_id should be formatted. With zero schema coverage, the description must compensate, and it does not.

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 ('Delete') and resource ('a document or folder from Alfresco'), which distinguishes it from sibling tools like upload_document, download_document, and create_folder. It is concise and unambiguous, though it doesn't explicitly differentiate from other delete-like operations (none exist among 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 provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or conditions (e.g., whether the node must be checked out, permissions required, or whether permanent deletion is appropriate). The sibling list includes checkout/checkin tools, but no exclusions or routing hints are given.

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 states that it downloads a document. It does not reveal that it can save to disk, whether the download is treated as an attachment, or any side effects on the repository. The behavior is fundamentally opaque beyond the basic action.

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

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

The description is a single, compact sentence with no filler or redundant phrasing. It is appropriately sized for a simple download action, and the main verb is front-loaded, 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?

Despite having 4 parameters and an output schema, the description omits crucial operational context such as default file save location, handling of existing files, or how the node_id is used. It does not explain return values or error conditions, leaving the agent with significant gaps in how to correctly invoke the tool beyond the schema.

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

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

Schema description coverage is 100%, so the schema already documents all parameters like node_id, attachment, save_to_disk, and destination_dir. The description adds no additional meaning or context about these parameters, so it neither helps nor hurts beyond the baseline for full 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 verb ('Download') and resource ('document from Alfresco repository'), making the primary purpose immediately obvious. It distinguishes itself from siblings like upload_document and checkout_document by the action itself, though it does not explicitly name alternatives or scope conditions.

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 any of the sibling tools (e.g., browse_repository, get_node_properties, or upload_document). It does not mention prerequisites, typical scenarios, or exclusions, leaving the agent without context for selection.

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. 'Get' implies a read operation, but the description does not disclose permissions, error behavior for invalid node IDs, access restrictions, or any other behavioral traits an agent should anticipate.

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. It is concise and easy to parse, though the brevity comes at the expense of useful detail.

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?

Even though the tool is simple and has an output schema, the definition lacks usage guidance, parameter semantics, and behavioral context. With no annotations, this sparse description is not enough for an agent to invoke the tool reliably in all situations.

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 provides only 'node_id' as a string, and the description does not explicitly explain what node_id is or how to obtain it. The phrase 'document or folder' gives some clue about the node type, but the parameter format and provenance are left undocumented.

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 ('metadata and properties of a document or folder'), distinguishing it from mutation tools like update_node_properties and delete_node. It does not explicitly differentiate it from retrieval alternatives like browse_repository or search_content, so it stops short of a perfect score.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention how to obtain a node_id, whether to use browse_repository or search first, or any prerequisites for calling this tool.

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 states the action and method but does not reveal whether the operation is read-only, what specific information is returned, any restrictions, or potential side effects. While it is likely a harmless read operation, the description does not explicitly confirm this, leaving the agent to infer it.

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, lean sentence that fronts the action and resource. Every word adds value; there is no fluff or repetition. It is appropriately concise for a tool with no parameters.

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 no parameters and an output schema, which reduces the need for descriptive detail about return values. The description fully covers what the tool does, and the output schema presumably details the returned information. The only gap is the lack of usage context relative to siblings, but given the simplicity of the operation, this is a minor omission.

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 is empty with zero parameters, so the description has no parameter meanings to clarify. Per the baseline for 0 parameters, this is a 4. The description correctly omits any parameter discussion, as there is nothing to explain 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?

The description states a specific action ('Get') and resource ('Alfresco repository information'), and adds the method ('using Discovery Client'). This clearly distinguishes it from siblings like browse_repository or get_node_properties, which focus on browsing or node-level details. The purpose is unambiguous.

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

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. The phrase 'as tool instead of resource' is a technical note about invocation style, not a usage condition. It does not mention when this is preferable to browse_repository, search, or other repository-level 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Search' and gives no detail about how multiple metadata fields combine, whether term is a partial/fuzzy match, case sensitivity, default behavior, or how results are ordered or limited. The read-only nature is implied but not stated.

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 redundancy, which is structurally clean. However, it is under-specified: it is concise primarily because it omits useful usage and behavior guidance rather than because every sentence is information-dense.

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 4 parameters, 0% schema coverage, no annotations, and multiple sibling search tools, the description is not complete enough for an agent to select and invoke the tool correctly. It lacks parameter semantics, use-case differentiation, and behavioral expectations; the existing output schema partially mitigates but does not compensate.

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 0%, and the description does not compensate by explaining term, creator, content_type, or max_results. 'By metadata fields' loosely connects the parameters to the search, but it adds little meaning beyond the parameter names and leaves max_results entirely unaddressed.

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 ('Search') and resource ('content in Alfresco') and identifies the mechanism ('by metadata fields'). However, it does not differentiate from sibling search tools like search_content, advanced_search, or cmis_search, so it misses the distinction needed for a 5.

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

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. With four sibling search/browse tools available, an agent gets no signal about whether metadata-field search is preferred for this query or how it differs from full-text or CMIS search.

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 that the tool searches content; it does not mention that the operation is read-only, how results are ordered or paginated, or whether special permissions or repository context are required.

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 extraneous words. It gets directly to the point and is easy to parse quickly.

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

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

The tool has 3 parameters and no annotations, and the description fails to explain the purpose of the optional parameters or any usage constraints. Although an output schema exists and the search concept is familiar, the missing parameter semantics and lack of behavioral context leave the description incomplete for confident invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning only to the 'query' parameter by identifying it as an AFTS query. The 'node_type' and 'max_results' parameters are not described at all, leaving their semantics to be guessed from parameter names.

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 action ('Search for content') and a specific resource ('Alfresco') with a concrete method ('AFTS query language'). This also distinguishes it from sibling tools like cmis_search and search_by_metadata, which use different search mechanisms.

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 the tool via the mention of 'AFTS query language', suggesting it is for AFTS-based queries rather than metadata or CMIS searches. However, it does not explicitly state alternatives or exclusion criteria, so an agent must infer the appropriate choice from sibling names 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 present, so the description must disclose behavioral traits, but it only states that it updates metadata and properties. It does not explain whether missing optional fields are overwritten or cleared, whether the update is idempotent, or what permissions are required. For a mutation tool this is a meaningful 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 concise sentence with the core operation front-loaded. It contains no filler, though its brevity means it does little to compensate for the lack of schema descriptions and usage guidance.

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 5-parameter mutation tool with no annotations and no parameter descriptions, this definition is incomplete. An agent cannot infer partial-update behavior, the effect of empty-string defaults, or when to choose this tool over get_node_properties or delete_node. The output schema may clarify return values but not invocation behavior.

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 0%, and the description adds no parameter-specific meaning beyond the phrase 'metadata and properties.' While names like node_id and title are somewhat self-explanatory, the description does not clarify relationships between parameters, default-value behavior, or how node_id acts as the identifier.

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 ('Update') and identifies the resource ('metadata and properties of a document or folder'). This clearly signals a mutation operation and distinguishes it from read-oriented siblings like get_node_properties and browse_repository. It is less explicit, however, in differentiating itself from other mutation tools beyond the 'metadata and properties' 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?

No guidance is given about when to use this tool versus sibling tools. The description does not mention alternatives, exclusions, or preconditions such as needing an existing node, which matters given the 14 sibling tools that include get_node_properties and delete_node.

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 says 'Upload a document' without explaining what happens on upload (e.g., whether it creates a new node, overwrites existing content, requires authentication, or handles versioning). The presence of both file_path and base64_content suggests two possible upload modes, but the description does not clarify their behavior or precedence.

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, which is concise and front-loaded. However, it is under-specified: it earns its place but does not provide enough information to be useful. It is not verbose, but it sacrifices substance for brevity.

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

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

Given the tool has 4 parameters, no annotations, and an output schema, the description is incomplete. It does not explain how to provide the document content (file_path vs base64_content), what the parent_id default means, or what the output schema contains. The sibling tools suggest a rich repository context, but this description does not help the agent understand the upload workflow.

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 0%, so the description must compensate for the four parameters, but it does not. The description mentions 'document' but does not explain the meaning of file_path, parent_id, description, or base64_content. The parameter names are somewhat self-explanatory, but the description adds no value beyond the schema, and the default values (e.g., '-shared-') are not explained.

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 ('Upload a document to Alfresco'), which is clear at a basic level. However, it does not distinguish this from sibling tools like create_folder or checkin_document, and it doesn't specify what kind of document or how the upload is performed. It is minimally clear but lacks 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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., needing a parent folder, using base64_content vs file_path), nor does it exclude cases like updating existing documents or checking in content. The agent is left to infer usage 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.