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

No annotations are provided, so the description carries full burden. It discloses that the tool returns a Document object on success and a ToolError on failure, and explains the identifier parameter's dual nature and prioritization. However, it could be more explicit about side effects like unlocking the document or permission 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 very concise: two paragraphs with no fluff. The first sentence states the core functionality, followed by a clear parameter description and return value documentation. Every sentence serves a 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?

For a tool with one required parameter and an output schema (not shown), the description covers the parameter semantics and return value. It could improve by providing examples or clarifying how the identifier string distinguishes between reservation_id and document_id, but it is largely 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 coverage is 0%, so the description must explain the parameter. It does so thoroughly: identifier can be reservation_id or document_id, with reservation_id prioritized. This adds significant meaning beyond the schema's 'string' type.

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 verb 'cancels' and the resource 'document checkout', making the tool's purpose unambiguous. It is distinct 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?

The description implies that the tool is used to undo a checkout, but it does not explicitly state when to use it or when not to, nor does it mention alternatives. The context from sibling tools helps, but the description itself lacks explicit 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 provided, so the description must convey behavioral traits. It discloses return type (Document or ToolError) and the fact that properties are updated, but does not mention required permissions, side effects, or prerequisites like checkout state.

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 structured as a docstring with parameter explanations, which is clear but somewhat verbose. It is appropriately sized for four parameters but redundant in places (e.g., 'Check-in action parameters for the document').

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 four parameters and returns an object. The description covers basic functionality but omits important context like prerequisites (e.g., document must be checked out) and detailed error conditions. Given the complexity, it is adequate 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 0% at the top level, but nested objects have descriptions. The description adds meaning for identifier (prioritization logic) and file_paths (file uploads), but other parameters are merely restated without additional guidance 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 clearly states the verb 'Checks in' and the resource 'document in the content repository', which differentiates from sibling tools like checkout_document. However, it does not explicitly contrast with siblings, missing 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 explains the identifier parameter prioritization but lacks explicit guidance on when to use this tool versus alternatives (e.g., checkout_document). Usage context is implied but not 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 partially discloses behavior: it mentions document property updates, optional download, and failure returns a ToolError. However, it does not clarify locking, permission requirements, or side effects, which are important for a checkout 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 concise and well-structured with a docstring format. It front-loads the main purpose and then lists parameters. Minor redundancy with return info, but overall 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?

Given no annotations and the presence of an output schema, the description covers the essential aspects: input parameters, return type (Document or ToolError), and a key behavioral note about download folder prompting. It is adequate for a checkout operation.

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 significant meaning beyond the input schema. It explains that 'identifier' can be an ID or path (e.g., '/Folder1/document.pdf'), and that 'download_folder_path' is optional and may prompt the user. Schema coverage is 0%, so the description fully compensates with clear parameter semantics.

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 'Checks out a document in the content repository' which is a clear verb-resource pair. It distinguishes from sibling tools like cancel_document_checkout and checkin_document by explicitly focusing on the check-out action.

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 provide explicit guidelines on when to use this tool versus alternatives. It lacks context on prerequisites or when not to use it, leaving the agent to infer 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?

Without annotations, the description carries the full burden. It explains return types (Document object or ToolError), default behaviors (GUID generation, class_identifier default), and a constraint (file_in_folder_identifier starts with '/'). It lacks details on authentication or side effects, but for a creation tool, this is sufficient.

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 somewhat verbose with repeated headers ('Description:') and a bold prerequisites section. While the information is front-loaded, it could be more streamlined. Two clear improvements: remove the redundant 'Description:' line and integrate prerequisites more concisely.

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's complexity (6 parameters, nested objects) and the presence of an output schema, the description covers creation prerequisites, parameter roles, and return types. It could mention idempotency or naming constraints, but overall it provides enough 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%, so the description must compensate. It provides meaningful explanations for all six parameters, including defaults, format requirements, and behavioral notes (e.g., 'CheckinMinorVersion should always be included'), adding value 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 explicitly states 'Creates a document in the content repository with specified properties,' clearly indicating the verb ('creates') and resource ('document'). This distinguishes it from sibling tools like checkout, checkin, or update, which have different primary actions.

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 explicit prerequisites in a numbered sequence, stating that determine_class and get_class_property_descriptions must be called first. While it doesn't explicitly state when not to use the tool, the creation use case is clear and different from siblings.

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 provided, but the description details parameter behaviors (e.g., id generation format), prerequisites, and return value (folder object or ToolError). Lacks details on permissions or conflict handling.

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?

Structured with prerequisites first, then main description, parameter list, and returns. Front-loaded with important usage info, though the param list uses non-standard format and could be more concise.

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?

Covers prerequisites, all parameters, and return values. Could be improved by explaining error conditions and folder_properties structure more clearly.

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%, but the description lists each parameter with type and description. However, folder_properties is poorly described as 'properties of to set' which adds little value 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 clearly states 'Creates a folder in the content repository' and lists specific parameters. It distinguishes from sibling tools like create_document and delete_folder by focusing on folder creation.

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?

Explicitly states prerequisites in order: must call determine_class and get_class_property_descriptions first. This provides clear sequential guidance for 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?

Annotations include destructiveHint=true, and the description adds that failure results in a ToolError. However, it does not disclose necessary preconditions (e.g., permissions, checkout status) or side effects beyond deletion. Some value added but incomplete.

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 concise with two clear paragraphs: purpose, then parameter and return details. No wasted words, though could be slightly more structured (e.g., bullet points for 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?

For a simple tool with one parameter and an output schema, the description covers purpose, parameter, and return value. However, it misses behavioral context like when deletion is allowed or restrictions (e.g., cannot delete last version). Could be more 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 coverage is 0%, but the description fully explains the single parameter 'identifier': it is required, can be a GUID ID or repository path, with an example. This compensates for the lack of schema descriptions.

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 'Deletes a specific document version in the content repository,' specifying the verb, resource, and scope. It effectively distinguishes from sibling tools like 'delete_version_series' or 'delete_folder'.

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 parameter requirements and return information but lacks explicit guidance on when to use this tool over alternatives like 'delete_version_series' or preconditions (e.g., version not checked out). Usage context is minimal.

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 discloses that it returns the folder id on success or a ToolError on failure. However, with no annotations provided, it omits critical behavioral details like whether deletion is recursive, permission requirements, or irreversibility.

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 reasonably concise, using a docstring-like format with param and returns. It is front-loaded with the main action but could be more streamlined by removing redundant statements about error returns.

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's simplicity (single required parameter) and the presence of an output schema, the description covers the basics. However, it lacks important context about effects on children, permissions, and when to use this over other folder operations.

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 a semantic description for the id_or_path parameter, clarifying it accepts either an ID or a path. Despite the schema having 0% description coverage, this is only a minimal addition beyond the parameter name itself.

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 tool name and description clearly state that it deletes a folder, using a specific verb and resource. It distinguishes itself from sibling tools like create_folder and update_folder by focusing on deletion.

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 folder deletion is needed, but provides no explicit guidance on when to use this tool versus alternatives (e.g., update_folder) or when not to use it.

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

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

Beyond the destructiveHint annotation, the description clarifies that it deletes all versions of a document and mentions potential failure with ToolError. This adds useful 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 concise (a few sentences), front-loaded with the core action, and every sentence provides necessary information without fluff.

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 destructive tool with annotations, the description is largely complete. It covers the parameter, return value, and error handling, though it omits permissions or side effects.

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 explains how to obtain the version_series_id (via get_document_property), which adds meaning beyond the schema's simple string type. With 0% schema coverage, this compensation is valuable.

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 it deletes an entire version series (all versions of a document), distinguishing it from sibling tools like delete_document_version which deletes a single version.

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?

Provides explicit guidance on obtaining the version series ID via get_document_property if not known. However, it does not explicitly state when to prefer this tool over alternatives like delete_document_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?

No annotations exist, so the description must disclose behavior. It explains substring matching, return of up to 3 classes with scores, and error on no matches. However, it omits details like case sensitivity or score meaning, leaving some 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?

Description is concise with a clear first sentence, structured :param/:returns format, and no redundant text. Each sentence 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?

Given the output schema existence and tool complexity, the description covers search method, parameters, return format, and prerequisite, making it fully adequate for agent use.

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 0%, but the description fully compensates by explaining root_class and keywords with examples and constraints (e.g., 'up to 3 words'), adding meaning beyond type definitions.

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 explicitly states the tool finds classes by substring matching in names and descriptions, clearly distinguishing it from siblings like list_root_classes or get_class_property_descriptions.

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 explicit prerequisite: 'MUST first call list_root_classes_tool' for valid class names, and gives parameter constraints (up to 3 keywords) and examples (root_class like 'Document').

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 fully discloses behavior: content search is performed first and then narrowed by metadata properties, search_term empty means metadata-only search, only released versions are returned, and a ToolError occurs if CBR is not enabled. This is comprehensive.

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 long but well-structured with sections for prerequisites, parameter details, notes, and an example. Every part serves a purpose, though the prerequisites could be slightly condensed. Overall, it earns its length for the tool's complexity.

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's complexity, nested parameters, and dependencies on other tools, the description is complete: it covers prerequisites, parameter semantics, behavioral notes, error conditions, and an example. An output schema exists, so return value details are not required. No gaps remain.

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?

Despite low schema description coverage (33%), the description adds substantial meaning: it explains search_term usage, how search_parameters inherit from prerequisites, the narrowing behavior of search_properties, and provides a complete example. This far exceeds the schema's minimal descriptions.

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 it searches documents by content and metadata criteria. It distinguishes itself from sibling tools like repository_object_search (searches other objects) and lookup_documents_by_name/path (different search methods), making its purpose specific and unambiguous.

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

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

The description explicitly lists a prerequisite sequence: must first call determine_class and get_searchable_property_descriptions. It also mentions that the tool errors if CBR is not enabled for content search, providing clear guidance on when to use and what conditions are required.

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?

While annotations already declare readOnlyHint=true, the description adds significant behavioral context: it confirms the operation places no reservation/lock, so no checkin or cancel is needed. It also details the return format (dictionary with document_id, files list) and failure mode (ToolError), which go beyond the annotations.

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 well-structured with a clear opening, usage context, parameter documentation using :param tags, and return documentation using :returns. It is concise but comprehensive, with no superfluous 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?

Given the tool's low complexity (2 parameters, output schema present), the description is fully complete. It covers purpose, behavior, parameters, return format, and error handling. No missing details are needed for an agent to invoke it correctly.

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 0% description coverage, but the description fully explains both parameters: identifier can be an ID or path, and download_folder_path is a required folder path that is created if missing. This adds critical meaning beyond the basic schema types.

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 that the tool downloads original content (e.g., raw PDF) without checking out the document, distinguishing it from sibling tools like checkout_document, checkin_document, and others. The verb 'downloads' and resource 'document content' are specific and unambiguous.

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

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

The description explicitly tells when to use this tool: when original file bytes are needed instead of extracted text. It also clarifies that no checkin or cancel checkout is needed, implying it's a read-only alternative to checkout. However, it does not explicitly state when not to use it, but the contrast with sibling tools provides indirect 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?

Beyond the readOnlyHint annotation, the description discloses that pages are rendered to images in memory, no data is written to disk, and no lock is placed on the document. It also mentions failure behavior (returns ToolError). This adds significant context about safety and execution.

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 well-structured with the core action first, followed by usage instructions, parameter details, and return value breakdown. It is slightly verbose but every sentence adds information. A minor simplification could improve 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 tool's complexity, single parameter, and presence of an output schema, the description fully compensates by listing all return fields, their types, and conditions. It explains the closure check for reliability and the mapping to map_easement_to_parcel, making it complete for an agent to use correctly.

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 only defines 'identifier' as a string, with 0% coverage. The description adds that it is a document id or path (required) and can be a GUID or repository path. While valuable, it could further specify acceptable formats or examples to be even more helpful.

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 it reads easement documents with a vision model and returns structured survey data for mapping. It specifies it works across different document qualities (clean PDF, OCR, image scan), differentiating it from sibling tools like get_document_pdf_text which only handle text extraction.

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 explicitly advises users to call this tool instead of parsing document text themselves, and directs the output into map_easement_to_parcel. This provides clear when-to-use and alternative guidance, leveraging the sibling tool 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 bears the full burden. It explains that the tool creates a referential containment relationship, returns a relationship ID on success, and returns a ToolError on failure. However, it does not mention permissions, idempotency, or what happens if the document is already filed.

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 moderately concise but includes structured param and return docs in reStructuredText format. It could be more succinct without losing clarity, but it is not overly 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?

The tool has a simple signature with two required parameters and no output schema provided in the definition. The description explains the return type and error handling, and given the low complexity and sibling context, it is largely 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?

The schema coverage is 0%, so the description must compensate. It provides parameter descriptions stating that 'document_id_or_path' is 'The unique identifier or path for the document' and similarly for the folder, adding meaning beyond the schema's mere type definition.

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 'File a document to a folder in the content repository' using a specific verb and resource, and distinguishes itself from sibling tools like 'unfile_document' and 'create_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?

The description implies usage by describing the action and parameters, but does not explicitly state when to use this tool versus alternatives like 'unfile_document' or 'create_document'. No when-not or exclusions 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 provided, so description carries full burden. It discloses it is a retrieval operation ('Retrieves'), but does not explicitly state safety or lack of side effects. However, the return type and parameter are explained. Minor gap for a read-only 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?

Two distinct sections: a short purpose sentence, then an IMPORTANT usage guideline, then parameter/returns. Every sentence adds value; front-loaded with 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?

Given an output schema exists, description need not detail return fields. It covers purpose, usage, parameter, and return type. Complete for a retrieval tool with one 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 has no description for the parameter (0% coverage). The description adds ':param class_symbolic_name: The symbolic name of the class to retrieve properties for', providing full semantic meaning 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 'Retrieves ALL properties of a class including system properties' – clear verb+resource with scope. It distinguishes from siblings like get_searchable_property_descriptions by emphasizing 'ALL' and 'system properties'.

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?

Explicitly says 'Use this tool ONLY for general document updates...' and 'DO NOT use for property extraction workflows' – clear when and when-not to use, with implied alternative 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?

Annotations already declare readOnlyHint=true; the description adds that no reservation/lock is placed and nothing is written to disk, and that scanned PDFs return empty pages, providing useful behavioral context beyond annotations.

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 concise, front-loads the core purpose, and efficiently uses sentences to cover usage, parameters, and return. No extraneous 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?

Given the output schema exists and the description explains the return dictionary, and the tool is read-only with a single parameter, the description covers all necessary aspects: purpose, when to use, parameter, and return value.

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%, but the description fully documents the single required parameter 'identifier', explaining it can be a GUID or path, and provides an example, thus adding complete 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 clearly states it extracts embedded text from a PDF's content bytes, and distinguishes itself from get_document_text_extract by explaining the difference in method and dependency on text extract annotations.

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?

Explicitly advises using when PDF text is needed but no text extract annotation exists, and warns against using for scanned PDFs without embedded text, recommending OCR or vision models instead.

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?

Describes successful return (Document object) and failure (ToolError), but lacks details about read-only nature, permissions, or other behavioral traits. With no annotations, more could be added.

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?

Description is concise and well-structured with a note, parameter doc, and return info. Slightly verbose but not excessive.

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 there is an output schema and one parameter, description covers key aspects: purpose, usage, parameter format, and return types. No obvious 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?

Input schema has 0% coverage, but description fully explains the parameter: it can be a GUID or path, with an example. This adds significant meaning 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 clearly states it retrieves document properties by ID or path. While it distinguishes from repository_search, it does not explicitly differentiate from other sibling tools like lookup_documents_by_path.

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?

Explicitly states when to use (by ID or path) and when not (use repository_search for other properties). However, it does not mention other sibling 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?

With no annotations, the description discloses key behaviors: concatenation of multiple extracts and returning empty string if none. This adequately covers the read-only nature and edge 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 concise with a clear first-line summary. The docstring format is well-structured, with no redundant sentences.

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 output schema exists, the description's return value explanation is sufficient. It covers the main cases but could mention error handling or authentication expectations.

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 sole parameter 'identifier' is explained as accepting either a GUID or path, adding meaning beyond the schema's plain string type. Since schema coverage is 0%, this compensation is valuable.

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 'Retrieves a document's text extract content,' using a specific verb and resource. It distinguishes from siblings like get_document_pdf_text and get_document_properties.

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 clear usage info for the identifier parameter and return behavior but lacks explicit guidance on when to use this tool versus alternatives (e.g., get_document_pdf_text).

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 provided, so description bears full load. It details return structure (past, current, future versions) but does not explicitly confirm read-only behavior or mention side effects, permissions, or error handling.

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 front-loaded with the main action and well-structured with param and returns sections. However, it is slightly verbose due to docstring formatting which could be more concise.

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 simple tool (1 param, returns version series details) and the presence of an output schema, the description covers purpose, parameter, and return structure adequately. Missing error conditions or prerequisites but still fairly 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?

The input schema has 0% description coverage for the 'identifier' parameter, but the description compensates by specifying that it can be a document ID (GUID) or path, adding significant meaning beyond just 'string'.

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 purpose: 'Retrieves all versions in the version series that includes the specified document.' It specifies the resource (versions in a series) and distinguishes from siblings like delete_document_version.

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 for fetching version history but does not explicitly state when to use this tool versus alternatives like delete_document_version. No guidance on prerequisites or when not to use.

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 provided, so the description bears full responsibility. It states it returns a Folder object or ToolError but lacks details on permissions, idempotency, or side effects. The description does not adequately disclose behavioral traits.

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 moderately concise but includes unnecessary details (wrong parameter documentation) and could be more front-loaded. The structure is adequate but not optimal.

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 presence of an output schema, the return value description is acceptable. However, the erroneous parameter information and lack of error context beyond ToolError make the description incomplete and potentially confusing.

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 only 'identifier', but the description incorrectly includes a non-existent 'folder_properties' parameter. This misleading information degrades semantics. Schema description coverage is 0%, so the description should compensate, but it adds erroneous content.

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 tool retrieves an existing folder's information given a folder ID. However, the mention of 'folder_properties' as a parameter (not in schema) introduces minor confusion, slightly reducing 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?

No guidance on when to use this tool versus siblings like 'get_folder_documents' or 'get_document_properties'. The description only states what it does, not when it's 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?

No annotations provided, so description must carry full burden. It only states 'retrieves' (read operation) but lacks details on permissions, error handling, pagination, or any behavioral traits 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?

Extremely concise: two sentences and a parameter description. No redundant information, front-loaded with purpose. 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 an output schema exists, description need not detail return, but it omits important context like pagination, filtering, sorting, or behavior on missing folder. Incomplete for a list-retrieval tool with many 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 coverage is 0%, but description explains the sole parameter can be 'folder id or path', adding meaning beyond the schema's mere type 'string'. This helps the agent understand usage, though format details are missing.

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 clearly states the verb 'Retrieves' and resource 'folder's contained documents'. Purpose is specific and easy to understand, but does not explicitly differentiate from sibling tools like get_folder_detail or document_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 on when to use this tool versus alternatives. No mention of prerequisites, exclusions, or context for invocation. Agent receives no help in deciding between this and siblings.

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 full burden. It mentions the return type (CachePropertyDescription objects) but does not disclose read-only behavior, authentication needs, error conditions, or side effects. The verb 'retrieves' weakly implies non-destructiveness but is insufficient.

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

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

The description is concise with a single sentence plus a structured parameter and return description. It is front-loaded and avoids unnecessary words, though the docstring format adds slight verbosity.

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 existence of an output schema, the description adequately covers the return type. It compensates for 0% schema coverage by explaining the parameter. However, it lacks information about errors, permissions, or behavior for invalid classes.

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?

With 0% schema description coverage, the description provides a clear parameter explanation: 'The symbolic name of the class to retrieve searchable properties for'. This adds meaning beyond the bare schema definition.

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 it retrieves only the searchable properties of a class. The verb 'retrieves' and target 'searchable properties' are specific. It distinguishes from the sibling tool 'get_class_property_descriptions' by limiting to searchable ones.

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 for retrieving searchable properties but does not explicitly state when to use this tool versus alternatives like 'get_class_property_descriptions'. No exclusions or prerequisites 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, the description must disclose behavior. It states the tool returns a list and gives an example, but does not mention side effects, authentication needs, rate limits, or other traits. For a zero-parameter read-only tool, this is adequate but not enriched.

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?

Four sentences: purpose, usage guideline, and return description. No extraneous words. Efficient 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?

Given zero parameters, existence of output schema, and simple purpose, the description fully covers what is needed. It explains the return value with an example, leaving no 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?

Input schema has 0 parameters with 100% coverage, so description need not add parameter info. Baseline of 4 is appropriate; the description does not detract.

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 tool lists all available root class types, with a specific verb ('list') and resource ('root class types'). It distinguishes from siblings by mentioning it should be called before 'list_all_classes', and provides an example return value.

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?

Explicitly says 'should be called first to get a list of valid root class names before using the list_all_classes tool', indicating when to use. Lacks explicit when-not or alternatives among the listed sibling tools, but is sufficient for this simple case.

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 states it returns a list of matching documents or a ToolError if no matches are found. It mentions confidence scores but does not disclose if the tool is read-only or any side effects. With no annotations, the description is adequate but could be more explicit about its behavioral traits.

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 well-structured with parameter documentation first, followed by a concise general description. It is reasonably concise, though the param descriptions are slightly verbose and could be tightened. Nonetheless, it front-loads important details.

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 presence of an output schema (not shown but indicated), the description covers the return type (DocumentMatch with name and confidence) and error condition. For a search tool with two parameters, the description is complete enough, though it could mention pagination or result limits.

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 thoroughly explains both parameters: keywords (up to 3 words, avoid common words) and class_symbolic_name (optional, use determine_class for lookup). Since the input schema has 0% description coverage, the description fully compensates, providing clear and actionable guidance 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 clearly states the tool searches for documents by name and returns matching documents. It specifies that it uses keywords from the user's message, distinguishing it from siblings like document_search or lookup_documents_by_path, though not explicitly naming 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 guidance on when to use the class_symbolic_name parameter and suggests using determine_class to find the symbolic name. However, it does not explicitly advise when to use this tool versus siblings like document_search or lookup_documents_by_path, leaving some ambiguity.

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 provided, so description bears full burden. It explains matching is based on containment names, returns a list of DocumentMatch objects or ToolError, and details parameter semantics. Covers all relevant behavioral aspects.

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?

Description is verbose and contains redundant sections (docstring-style followed by separate 'Description:' line). Could be more streamlined. Front-loading is decent with prerequisite in bold, but overall structure is cluttered.

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's complexity (two parameters, no annotations, output schema exists), the description sufficiently covers usage and behavior. Lacks details on error types beyond ToolError, but overall complete for agent use.

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 has 0% description coverage, but description compensates fully. Explains keywords_at_path_levels as list of lists with constraints (up to 3 words per level, avoid common words) and class_symbolic_name as optional with default root class. Adds meaning beyond 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 tool searches for documents based on their folder path. It distinguishes from sibling lookup_documents_by_name by mentioning path separator usage and 'rather than a more basic lookup by name'.

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?

Explicitly requires calling determine_class first as a prerequisite. Provides guidance on when to use this tool (path separator) and how to construct the keywords parameter. No exclusions, but clear 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?

Aligns with readOnlyHint annotation, describing no repository operations. Details return structure (summary, geojson_io_url, geojson) and failure behavior (ToolError). Adds guidance on how to present results, e.g., 'NEVER re-type coordinates.'

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?

Well-structured with clear sections: purpose, parameter details, returns. Some verbosity, but each part earns its place given complexity. Could be slightly more compact but still effective.

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?

Comprehensive for a tool with 15 parameters and geospatial context. Covers purpose, every parameter, return values, and usage instructions. Output schema exists, so return description is adequate.

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?

Despite 0% schema description coverage, the description provides thorough explanations for all 15 parameters, including formats, examples, conditional usage, and defaults. Compensates 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?

Stated clearly: 'Places an easement survey traverse onto real-world map coordinates and returns GeoJSON.' Differentiated from sibling tools (document management) by being a pure geospatial computation.

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?

Explicitly states it performs no repository operations and is a pure computation, indicating when to use. For parameters, describes optional conditions. Could be improved by stating when not to use, but context is clear enough.

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 implies a read-only operation ('retrieves') but does not explicitly state safety or side effects; however, it does describe return structure in detail.

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 verbose with a prerequisite block and param docs that repeat schema; while the prerequisite info is valuable, the structure could be more concise 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?

Given the tool's complexity (nested params, no annotations), the description covers prerequisites and return structure, making it mostly complete. Missing details on pagination or error handling keep it from a 5.

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 description's param docs largely mirror the schema. The description adds no new meaning beyond the schema, 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 states it 'retrieves repository objects other than Document instances,' which is specific verb+resource and distinguishes it from the sibling tool 'document_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?

The description explicitly lists prerequisites in order (determine_class then get_searchable_property_descriptions) and implies this tool is for non-document objects, providing clear when-to-use and when-not-to-use 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?

Without annotations, the description carries the transparency burden. It mentions using the GraphQL API and indicates success returns a folder ID, while failure returns a ToolError. However, it does not disclose whether the operation is destructive or requires authentication.

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 fairly concise, starting with the primary purpose and including parameter details. The docstring format is slightly lengthy but well-organized.

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 tool with two required string parameters, the description covers purpose, parameter semantics, and return value. It is adequate for an agent to understand and invoke the tool correctly.

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 includes docstring-like parameter documentation explaining that folder_id_or_path and document_id are unique identifiers and that they are required, adding meaning beyond the schema's type-only definitions.

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 tool's purpose: 'Unfile a document from a folder in the content repository.' This directly matches the name and distinguishes it from sibling tools like file_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?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or common usage scenarios. It only describes the basic operation.

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?

Discloses the destructive potential (property loss if new class lacks properties) and that the tool does not update properties. Does not mention permissions or rate limits, but with no annotations, the description carries a fair burden and provides important 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?

Well-structured with prerequisites, description, warning, and parameter details. Front-loaded with critical information. Slightly lengthy but each part serves a purpose. Could be more concise without losing 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?

Covers prerequisites, operation, side effects, and return values. With no annotations, it provides sufficient context for a mutation tool. Could specify class_identifier format and if the new class must 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?

The input schema has no descriptions (0% coverage), but the description explains identifier accepts document id or path and class_identifier is the new class identifier. Provides an example for identifier. This adds meaning 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 clearly states the tool changes a document's class in the content repository. It distinguishes from siblings by explicitly noting it only changes class and not properties, and points to update_document_properties for property updates.

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?

Provides prerequisites: must call list_all_classes or determine_class first. Advises when to use the tool (class change) and when not to (property updates), offering explicit 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?

With no annotations, description carries full burden. It discloses mutability (updates properties), return values (Document object or ToolError), and identifier formats. However, it does not specify merge vs overwrite behavior for properties, concurrency, or permission 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?

Structured with prerequisites, description, parameters, and returns. Front-loaded important usage guidance. Slightly verbose but well-organized.

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?

Covers purpose, prerequisites, parameters, return types, and sibling differentiation. Lacks details on behavioral specifics like idempotency and property overwrite semantics. Output schema existence reduces need to describe Document object.

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 has 0% top-level description coverage, but nested properties have descriptions. Description adds value by clarifying identifier as GUID or path and listing key updatable properties (name, mimeType, etc.), though it does not enumerate all subfields explicitly.

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 clearly states it updates document properties, specifying verb and resource. It explicitly differentiates from the sibling tool update_document_class, eliminating ambiguity.

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?

Prerequisites section mandates calling property_extraction or get_class_property_descriptions first, providing explicit when-to-use guidance. It also clarifies this tool does not change class and directs to the appropriate sibling for that.

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, and the description only mentions returning a Folder object or ToolError. It does not disclose potential side effects (e.g., overwriting properties), required permissions, or other behavioral traits beyond the basic update 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 includes a separate prerequisites section and docstring format, which provides structure but is somewhat verbose. It could be more concise by integrating prerequisites into the main flow.

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 covers key aspects: prerequisites, parameters, and return type. However, it does not explain error scenarios fully or how to obtain identifiers. Given the output schema exists but is not shown, completeness is adequate but not outstanding.

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 meaningful parameter details beyond the schema, such as identifier being a GUID or path, and class_identifier allowing class change. Schema coverage is 0%, so the description compensates well.

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 tool updates an existing folder with properties. It distinguishes from sibling tools like create_folder and delete_folder. However, the inclusion of prerequisites makes the purpose slightly less immediate.

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 explicitly provides a prerequisite sequence (determine_class then get_class_property_descriptions) and notes when to call them, offering excellent guidance on when and how to use this tool.

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