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

No annotations provided, so description carries full burden. It explains submission process, shared config, and return IDs, but omits execution model (async vs sync), error handling, auth needs, or side effects (e.g., resource creation).

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 Args, Returns, Examples sections and front-loaded purpose. Slightly verbose in describing shared config, 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?

Comprehensive for a batch submit tool: covers inputs, output (task_ids and function_ids), and shared config. Missing error scenarios, limits, and permission requirements, but sufficient given output schema existence.

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 coverage, description fully compensates by detailing every parameter, including nested task fields (function_source, function_name, args, kwargs) and optional configs, plus a concrete example.

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?

Clear verb 'submit' with specific resource 'multiple Python functions as a batch', directly distinguishing from sibling compute_submit (single function). The term 'batch' and mention of shared config reinforce unique 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?

Description implies batch submission for multiple tasks with shared endpoint and config, contrasting with single-task submit. However, it lacks explicit when-not-to-use or alternative references beyond the name.

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

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

Thoroughly describes that only accessible endpoints are returned and includes role filtering. While read-only nature is implied, no annotations exist, and the description does not explicitly state it is side-effect-free, but the level of detail is high.

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 yet comprehensive, with clear sections (purpose, note, args, returns, examples). Each sentence adds value, and the structure allows quick scanning.

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 description adequately summarizes the return format. It covers the core functionality, parameter, and provides examples, leaving no critical gaps for an AI agent.

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

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

The description provides complete semantic detail for the 'role' parameter beyond the bare schema: it defines the filter, lists acceptable values ('any', 'owner'), and specifies the default, fully compensating for 0% schema description coverage.

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

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

The description clearly states 'List Globus Compute endpoints accessible to the current user' and explains its use for finding a UUID by name, distinguishing it from siblings like compute_endpoint_status and endpoint_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?

Explicitly advises when to use (to match user's request against display names) and when not to (keyword search not available as for Transfer endpoints), with a clear fallback instruction to ask for UUID.

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 discloses that the tool is a read-only check with no side effects, and specifies the return includes online status and readiness. No hidden behaviors are indicated.

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 structure: purpose, usage guidance, args, returns, and an example. Every sentence provides value without redundancy.

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 one simple parameter, the description fully covers purpose, usage, parameter meaning, and return type. The example aids clarity, making it complete for this tool.

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

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

With 0% schema description coverage, the description adds meaning by stating endpoint_id is a UUID of the Compute endpoint, beyond the schema's bare 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 tool checks endpoint online status, with specific verb 'Check' and resource 'whether a Globus Compute endpoint is online'. It distinguishes from siblings like compute_submit by noting its role as a prerequisite check.

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 using this tool before submitting tasks to verify availability, providing clear context. However, it does not list explicit alternatives 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?

Discloses that it opens a browser window and requires user interaction to complete login. No annotations are provided, so the description carries the full burden. It could mention that this is a non-blocking call, but the behavior is well explained.

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?

Concise, structured with sections for behavior, note, and returns. Every sentence adds value, no fluff. Front-loaded with key action and differentiation.

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 parameters and existence of output schema, the description fully covers the tool's purpose, behavioral side effects, and return value. Complete for a simple login tool.

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

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

Input schema has zero parameters, so description adds essential context about the login flow being browser-based and separate from CLI login. Schema coverage is 100%, and description enhances understanding.

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

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

Clearly states the tool initiates Globus Compute OAuth login flow, distinguishing it from the Globus CLI login used for transfers. The verb 'initiate' and resource 'Globus Compute OAuth login flow' are specific, and the sibling tool 'globus_login' is explicitly differentiated.

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 (before submitting compute tasks) and when not to (for transfers, use Globus CLI login). Directly mentions the alternative 'globus_login' for transfers, providing clear 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 provided, so description carries full burden. It transparently describes non-blocking vs. polling behavior, exponential backoff, and the exact return structure (status, result, exception).

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 well-structured with sections for purpose, behavior, args, returns, and examples. Every sentence adds value without redundancy.

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 and presence of an output schema, the description covers all necessary aspects: input parameters, behavior variants, return format, and usage examples.

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 coverage, description compensates fully. It explains 'task_id' as UUID of the task and 'timeout' with semantics of blocking vs. non-blocking, including default, and provides concrete examples.

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 'Get the result of a Compute task' with specific verb and resource. It distinguishes from sibling tools like compute_submit and task_wait by focusing on result retrieval.

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

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

The description explains when to use the tool: to retrieve task results. It details non-blocking behavior without timeout and polling with timeout, but does not explicitly mention when not to use it or direct alternatives among 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 carries the full burden. It explains that the tool is non-blocking and details the return values including pending, status, result, and exception. This gives a clear picture of behavior.

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

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

The description is concise at 6 lines, structured with Args, Returns, Examples. Every part is informative with no unnecessary text.

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 single-parameter tool and the presence of an output schema, the description is complete. It covers the parameter, return values, and usage pattern, leaving no gaps for an AI agent.

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

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

With 0% schema description coverage, the description compensates fully. It explains that task_ids are list of UUID strings from specific submission tools and provides an example usage, adding 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 checks the status of Compute tasks, non-blocking. It uses a specific verb 'check' and resource 'status of Compute tasks', distinguishing it from siblings like compute_submit which submit tasks.

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 specifies that task_ids should come from compute_submit or compute_batch_submit, implying context. However, it does not explicitly state when not to use this tool vs alternatives like task_wait, which would be a blocking equivalent.

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. Discloses asynchronous behavior, registration step, return format (task_ids and function_id), and auto-generation of worker_init. Does not mention error handling or timeouts, but covers key behaviors.

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 overview, important note, Args section, Returns, and Examples. Each sentence adds value, no redundancy. Front-loaded with purpose. Efficient use of space given the 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 complexity (8 parameters, no annotations, output schema exists), the description is thorough. Covers workflow, parameter details, constraints, and examples. Could mention that function_source must be a valid function definition, but this is implied.

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%, and description compensates fully. Each parameter is explained with purpose, format, and defaults. Examples demonstrate usage for multiple scenarios, including optional parameters like requirements and args. Adds significant 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 the tool submits a Python function for remote execution on a Globus Compute endpoint. It uses a specific verb ('submit') and identifies the resource ('Python function for remote execution'). It distinguishes from sibling tools like compute_batch_submit and compute_result by focusing on single function submission.

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 context on asynchronous submission, immediate return, and requirements for third-party packages. References sibling tool compute_endpoint_list() for finding endpoints. Does not explicitly state when not to use this tool or compare to alternatives, but the constraints are clear.

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 async behavior, return value (task_id), and parameters like recursive and ignore_missing. Could mention irreversibility or permissions but sufficient for 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 separate sections for description, args, returns, and examples. Every sentence adds value without redundancy.

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 all aspects: async operation, parameter details, monitoring method, and example. Output schema exists for task_id, which is described in 'Returns'.

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?

All five parameters are explained in the Args section with clear meanings (endpoint_id, path, recursive, ignore_missing, label), compensating for 0% schema description 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?

Clearly states it submits an async delete task, distinguishes from synchronous 'rm' sibling by noting it returns immediately with a task_id.

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 contrasts with 'rm' and directs to use task_show/task_wait for monitoring. Provides example usage and parameter descriptions.

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

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

The description discloses that the tool returns a UUID string and raises GlobusError if GCP is not installed or running. No annotations are present, but the description adequately covers behavioral traits for a simple read operation.

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

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

The description is concise with a clear first sentence, followed by return info, error conditions, and an example. Slightly verbose with separate lines for Returns/Raises but still 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 zero parameters and an existing output schema, the description is complete: it explains the return value, error case, and provides a usage example. No gaps are apparent.

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

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

The tool has zero parameters and schema coverage is 100%. A baseline of 4 is appropriate as the description adds no unnecessary details about parameters.

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

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

The description clearly states the tool's purpose: 'Get the UUID of the locally installed Globus Connect Personal endpoint.' It specifies the verb (Get) and resource (UUID of local GCP endpoint), and distinguishes from siblings like endpoint_search by being local-specific.

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

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

It explains the returned ID can be used as a source or destination for transfers, providing an example with transfer(). While it doesn't explicitly list when not to use, the context is clear and sufficient for selecting this tool.

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

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

No annotations are provided, so the description fully describes behavior: it is a read-only search returning endpoint metadata. It does not cover rate limits or auth, but given the nature of the tool, the description is transparent enough.

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 Args, Returns, and Examples sections. It is somewhat lengthy but every sentence adds value. Front-loaded with the main purpose.

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

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

The description covers the tool's purpose, all parameters, return format, and usage examples. Given the complexity of the tool and the presence of an output schema, the description is complete and self-contained.

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 fully compensates by detailing all three parameters: query (search text), filter_scope (with all options), and limit (range and default). This adds significant meaning beyond the raw JSON 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 'Search for Globus endpoints by name or keyword' and explains endpoints are storage systems for data transfer. This specific verb+resource purpose distinguishes it from sibling tools like compute_endpoint_list.

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?

It explicitly says to use this to find UUIDs for data transfers, and provides examples. It does not explicitly exclude use cases or mention alternatives, but the context is clear and sufficient.

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 burden. It states it returns a dict with details, implying a read operation. However, it does not explicitly confirm read-only, mention authentication needs, or discuss side effects. Adequate for a simple lookup 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 brief, well-structured with a summary line, args section, returns section, and an example. Every part is relevant and no redundancy.

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 covers purpose, parameter meaning, return fields, and provides an example. It is complete for its simplicity.

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 explains the param as 'The UUID of the endpoint' and provides an example call. This adds meaningful context beyond the schema's bare 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 'Get detailed information about a specific endpoint', specifying the verb 'Get' and the resource 'endpoint'. The example further clarifies usage with a UUID. This distinguishes it from siblings like 'endpoint_search' (search) and 'compute_endpoint_list' (list).

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 (have an endpoint UUID) but does not explicitly compare to alternatives like endpoint_search or compute_endpoint_list. No guidance on when not to use or prerequisites. Minimal but not absent.

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, but the description fully discloses that it opens a browser, stores credentials locally, requires user completion in browser, and returns a status message. This is thorough for a login 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 concise with clear sections, each sentence adds value. It is appropriately sized and front-loaded with the core action.

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 parameters and an output schema (implied by return value description), the description covers the login flow, browser interaction, credential storage, and return status. It is complete for this tool.

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

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

There are no parameters, so the schema provides complete coverage. The description adds behavioral context (browser opening, authentication flow) beyond the schema, which is helpful but not parameter-specific.

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 initiates the Globus OAuth login flow, specifying the verb 'Initiate' and the resource. It distinguishes itself from sibling tools like compute_login by mentioning 'Globus OAuth' and the browser-based flow.

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 (first step for authentication) but does not explicitly state when not to use or mention alternative tools. It provides clear context but lacks explicit 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, the description must disclose behavior. It explains the recursive depth limit (up to 3), hidden file handling (all flag), and detailed metadata (long flag). However, it does not mention error handling 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?

Well-structured with Args, Returns, and Examples sections. The description is not overly verbose but could be slightly more concise (e.g., avoid repeating 'if None'). Every 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 an output schema exists (as per context), the description covers the main behavior and return structure. It lacks details on error cases or default directory behavior, but is sufficient for basic usage.

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 fully explains all 5 parameters with purpose and effects. Examples demonstrate combined usage. Each parameter (endpoint_id, path, all, long, recursive) is clearly described.

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 'list the contents of a directory' on a Globus endpoint, using a specific verb and resource. It distinguishes itself from sibling tools like mkdir, rm, and transfer by focusing on listing operations.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., stat for single file metadata, transfer for file movement). The description includes default behavior hints (e.g., path=None) but lacks comparisons or when-not-to-use conditions.

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

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

Annotations are absent, so the description carries the burden. It mentions return type (dict with 'message' and 'code') but fails to disclose critical behavior such as error handling (e.g., if directory already exists), required permissions, or whether parent directories are created.

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 (80 words) and well-structured with Args, Returns, and Examples. Every sentence is informative, with no waste.

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 (2 required parameters) and presence of an output schema (though not shown), the description adequately covers purpose, parameters, return value, and examples. Minor lack of behavior on existing directories prevents a perfect score.

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 fully explain parameters. It does so clearly: endpoint_id is 'The UUID of the endpoint' and path is 'Path where the directory should be created', adding substantial meaning beyond the property 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 the action 'Create a directory' on a specific resource 'Globus endpoint', with a specific verb and resource. It distinguishes from sibling tools like ls, rm, transfer, which have different purposes.

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

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

No guidance on when to use this tool versus alternatives. It does not mention prerequisites or scenarios where mkdir is appropriate compared to other tools like transfer or rename.

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 preconditions and return format, but lacks details on permissions, error behavior, or idempotency. Minimal but adequate for basic understanding.

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: purpose first, then preconditions, parameter list, return value, and examples. Every sentence adds value, with no redundancy or unnecessary 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?

Covers purpose, parameters, preconditions, return value, and gives practical examples. Missing error handling or permission requirements, but for a simple rename operation this is largely sufficient.

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 includes an 'Args' section with concise descriptions for all three parameters (endpoint_id as UUID, source_path as current path, dest_path as new path), effectively compensating for the schema gap.

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 'Rename or move a file or directory on a Globus endpoint,' specifying the action and resource. It distinguishes from siblings like 'transfer' which handles cross-endpoint moves, making the purpose 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?

Provides clear preconditions: source must exist, destination must not exist, and most endpoints require same filesystem. Does not explicitly compare to alternatives, but context signals (sibling list) allow inference, so usage guidance is adequate.

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 full burden. It discloses that the tool submits a delete task and blocks until complete, explains parameters like recursive, ignore_missing, timeout, and mentions return value. Good transparency, but could mention error behavior.

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

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

Well-structured with summary, explanation, Args, Returns, and Examples. Every sentence adds value; no wasted words. Appropriate length for the tool 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?

Covers purpose, usage guidance, parameter details, behavioral notes, return info, and examples. Given an output schema exists, the description is complete enough for an agent to select and invoke correctly.

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

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

Schema has 0% description coverage; the description compensates fully by documenting all 5 parameters in Args section with clear explanations and examples, adding substantial 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 'Delete a file or directory and wait for completion' with a specific verb and resource. It distinguishes the blocking nature from potential asynchronous siblings like 'delete' or task-based tools.

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

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

Explicitly says 'Use this when you need to ensure deletion is finished before proceeding.' Provides clear context for when to use, though does not explicitly list alternatives 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 carries full burden. It discloses that the tool 'open[s] the user's browser' and requires user interaction to grant access. This is important behavioral context. Minor gap: doesn't describe behavior if consent is denied or browser fails, but sufficient for typical use.

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: a one-sentence purpose, followed by usage context, then Args and Returns sections. No redundant or extraneous content.

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

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

For a simple tool with one parameter and a straightforward purpose, the description covers the key aspects: what it does, when to use, parameter details, and return value. It lacks edge-case handling (e.g., user closes browser) but is comprehensive for the intended use case.

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 only defines 'scopes' as a string. The description adds valuable semantic detail: 'One or more scope URN strings (space-separated) from the ConsentRequired error response.' This explains the format and source of the parameter, compensating for the 0% schema description 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 the tool's purpose explicitly: 'Grant consent for endpoint-specific data access.' It explains the scenario (ConsentRequired error) and distinguishes this tool from sibling tools like 'ls', 'transfer', 'stat', which are operations that may require consent.

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 clear when-to-use guidance: 'When operations like ls(), transfer(), or stat() fail with a ConsentRequired error, call this tool.' Also instructs to retry the original operation after consent, effectively covering usage flow.

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

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

No annotations are provided, so the description carries the burden of behavioral transparency. It indicates a read-only operation ('status/metadata') and details the return fields. It does not mention side effects (none expected) or error handling, but the basic behavior is well-covered.

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 clear sections (Args, Returns, Examples). It is concise, with no unnecessary words, and front-loads the purpose. Every 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?

The tool is simple with two parameters and a well-documented return format. The description covers all necessary information for an agent to use it correctly, even without an output schema. It is complete for the given complexity.

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 explicitly defines both parameters with types and purposes: 'endpoint_id: The UUID of the endpoint' and 'path: Path to the file or directory'. Since schema coverage is 0%, this fully compensates by adding meaning beyond the raw 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 verb 'Get' and resource 'status/metadata of a file or directory on an endpoint'. It distinguishes from sibling tools like 'ls' (which lists directory contents) by focusing on metadata retrieval.

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

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

The description provides examples that illustrate typical usage but does not explicitly state when to use this tool versus alternatives, such as when to prefer 'ls' for listing or 'stat' for metadata. No exclusion criteria or prerequisites are mentioned.

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

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

No annotations are provided, so the description fully carries the burden. It states the tool cancels tasks, implies destructive action, and scopes it to the user's in-progress tasks. It mentions a confirmation dict in return but does not detail irreversibility or side effects, which is acceptable for a cancellation 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 well-structured with a summary line, bullet points, and examples. It is front-loaded with the main action. Some minor redundancy (e.g., 'Dict with cancellation confirmation') could be trimmed, 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 that an output schema exists (not shown but indicated in context), the description need not explain return values. It covers input, exceptions, and examples thoroughly. No gaps remain for a cancellation tool.

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

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

Schema description coverage is 0%, so the description must compensate. It thoroughly explains both parameters: task_id (UUID string, optional if all=True) and all (boolean). It adds the context that at least one must be provided, with examples showing exact usage patterns.

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 cancels running or queued tasks, distinguishing between canceling by ID or all tasks. It uses the specific verb 'cancel' on the 'task' resource and differentiates from sibling tools like task_list, task_show, task_wait, and task_event_list.

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 provides when to use each parameter: either provide task_id or set all=True. Includes a ValueError condition if neither is provided, and gives two clear examples demonstrating both use cases.

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

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

No annotations are provided, so the description carries full burden. It reveals that events include faults, tasks older than a month may lack history, and the return format. Missing explicit mention of read-only nature or potential side effects, but the behavior is adequately conveyed.

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 brief intro, a note, and separate sections for Args, Returns, and Examples. Every sentence adds value, and the key information is 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 4 parameters and an existing output schema, the description covers purpose, parameters, return structure, and a usage caveat. It lacks details on permissions, error handling, or pagination behavior for large limits, but remains 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?

Schema coverage is 0%, yet the description provides clear parameter docs: task_id as UUID, limit default 10, filter_errors and filter_non_errors booleans with descriptions. It explains their purpose but lacks detail on behavior when both filters are set simultaneously.

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 'Get recent events for a task,' specifying a concrete verb and resource. It distinguishes from sibling tools like task_list (which lists tasks, not events) by focusing on events and including debugging context.

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 notes that events include faults and are useful for debugging transfer issues, and adds a constraint about task age. However, it does not explicitly list when not to use this tool or suggest alternatives, so some guidance is implicit.

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 only mentions 'list', implying read-only, but doesn't explicitly state that it is safe, non-destructive, or discuss rate limits or authentication needs. Missing 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?

Description is concise (9 lines including examples), well-structured with Args, Returns, Examples. 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 no annotations and low complexity (2 optional params, simple list return), the description is complete: covers purpose, parameters, return fields, and provides examples. No output schema exists, but return fields are listed.

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 adds meaning: explains 'limit' default and 'filter_status' possible values with examples. Provides context beyond schema, though case sensitivity or exact formatting is not specified.

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 'List recent transfer and delete tasks', providing a specific verb and resource. It distinguishes from sibling tools like task_show (detailed view) and task_event_list (events).

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?

Examples imply usage (e.g., filtering by status), but no explicit guidance on when to use this tool versus alternatives like task_show or task_event_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?

No annotations are provided, so the description bears full responsibility. It lists return fields but does not disclose read-only behavior, authorization needs, error conditions, or rate limits. The 'Returns' section is helpful but lacks safety/operational context.

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

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

Every sentence serves a purpose: summary, arg description, return fields, and example. Front-loaded and no filler. Well-organized into sections (Args, Returns, Examples).

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 single parameter, the description fully documents what is returned. The output schema exists (context signal), but the description still provides rich detail on fields. It does not explicitly differentiate from sibling tools, but the purpose is clear enough. Slightly incomplete for a fully standalone description, but more than 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?

The schema specifies task_id as a string with no description (0% coverage). The description clarifies it is 'The UUID of the task' and provides an example, adding essential 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 'Get detailed information about a specific task', with a specific verb ('get') and resource ('task'). It distinguishes from sibling tools like task_list (list all tasks) and task_cancel (cancel), making its purpose unambiguous.

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

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

Usage context is implied (e.g., when you need details of a specific task), but there is no explicit guidance on when to use this tool versus alternatives like task_list or task_event_list. No when-not-to-use or prerequisites mentioned.

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

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

In the absence of annotations, the description fully discloses behavioral traits: it blocks until completion or timeout, specifies timeout behavior (None waits indefinitely), polling interval, return values ('SUCCEEDED', 'FAILED' with reason), and exceptions ('GlobusError').

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 clear sections (Args, Returns, Raises, Examples) and uses concise sentences. Every line adds value, avoiding redundancy.

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 purpose (blocking wait with timeout), the description covers all necessary aspects: behavior, input parameters, output structure, error handling, and usage examples. It is 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?

With 0% schema description coverage, the description fully compensates by explaining each parameter: task_id as UUID, timeout as maximum seconds (default None), polling_interval as seconds between checks (default 1). Examples illustrate usage.

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 'Wait for a task to complete' with a specific verb and resource. It distinguishes itself from sibling tools like 'task_cancel' and 'task_show' by focusing on the wait/blocking behavior.

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?

It advises using this tool when 'you need data in place before proceeding with subsequent operations', providing clear context. However, it does not explicitly exclude alternatives or mention 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?

No annotations are provided, so the description carries full burden. It discloses the async behavior and monitoring needed but lacks details on permissions, rate limits, or potential overwrite behavior (though sync_level implies it). Could be more transparent about prerequisites and what happens to destination files.

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 sections for summary, args, returns, and examples. However, it is somewhat lengthy; the examples could be condensed or moved to reduce verbosity 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?

Given the tool's complexity (10 parameters, required fields, async behavior), the description is fairly complete. It covers behavior, parameter details, return value, and usage examples. Minor gaps in behavioral transparency (permissions, error handling) prevent a perfect score.

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 provides thorough explanations for all 10 parameters, including sync_level options with valid values. Examples further clarify parameter usage, adding significant 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 it submits an asynchronous transfer task between Globus endpoints, specifying the verb and resource. It distinguishes from siblings like transfer_batch and compute_* tools.

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

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

The description explains the asynchronous nature and suggests using task_show() or task_wait() for monitoring. It provides examples but does not explicitly state when not to use this tool versus alternatives like transfer_batch.

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

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

No annotations are provided, so the description carries full burden. It describes the return value as a dict with 'task_id' and details, and explains parameter behavior. It does not discuss side effects, permissions, or error conditions, but given the nature of a batch transfer, the description is fairly transparent.

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

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

The description is well-structured with sections for summary, args, returns, and examples. It is slightly verbose but front-loads the purpose and remains readable.

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 8 parameters, no annotations, and an output schema (not shown), the description covers inputs, output, and provides an example. It could include error handling or status details, but overall it is sufficient for an agent to use the tool.

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

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

Schema description coverage is 0%, but the description provides detailed explanations for each parameter, including structure for 'items', optionality for 'sync_level', and boolean flags. This adds significant meaning beyond the raw 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 'Submit a batch transfer with multiple file pairs' and includes 'More efficient than multiple individual transfers', which distinguishes it from sibling tools like 'transfer'.

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 says 'More efficient than multiple individual transfers', indicating when to use it. It provides an example but lacks explicit when-not-to-use or alternative conditions. However, the context is clear.

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 must convey behavioral traits. It states the tool returns identity information but does not explicitly confirm it is read-only or disclose side effects. The return format and example add some context, but lacks details on error cases (e.g., when no user is logged in).

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 three clear sections: purpose, return format, and example. The example is useful but the 'Returns:' line slightly repeats the first sentence. Overall efficient with minimal waste.

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 no parameters and an output schema, the description covers the main functionality and typical return value. However, it omits prerequisites (e.g., user must be logged in) and error handling. Acceptable but not exhaustive.

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 no parameters, so schema coverage is 100%. The description adds no parameter semantics, but the example with empty parentheses implicitly confirms no arguments are needed. A baseline of 4 is appropriate for zero-parameter tools where the schema already covers everything.

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

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

The description clearly states the tool shows the currently logged-in Globus identity, distinguishing it from sibling tools like globus_login (which handles authentication) and compute_login (which manages compute sessions). The verb 'show' combined with the specific resource 'current Globus identity' provides precise purpose.

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

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

The description implies usage for checking the current identity but does not provide explicit guidance on when to use this tool versus alternatives (e.g., globus_login for initiating login). No exclusion criteria or when-not-to-use guidance is given.

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