MCP Server Box

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool moves a folder but doesn't describe key behavioral traits: whether this operation is reversible, what happens to subfolders and files within the moved folder, whether it requires specific permissions, or potential side effects like breaking shared links. The return value is vaguely described as 'Dictionary containing the moved folder object or error message,' lacking details on success/error formats.

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 appropriately sized and front-loaded, with the core purpose stated in the first sentence. The Args and Returns sections are structured clearly, though the inclusion of 'ctx: Context: The context containing Box client information' is redundant with typical MCP patterns and could be omitted for better 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 complexity of a mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It lacks essential context such as error handling, permission requirements, behavioral details (e.g., impact on nested items), and clear return value specifications. For a tool that modifies data, this level of documentation is insufficient for safe and effective 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 description coverage is 0%, so the schema provides no parameter descriptions. The description adds basic semantics by naming the parameters (folder_id, destination_parent_folder_id) and indicating they are IDs, but it doesn't explain format requirements (e.g., numeric vs. string IDs), validation rules, or what happens if the destination doesn't exist. This partial compensation justifies a baseline score, but significant gaps remain.

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 ('Moves a folder') and resource ('in Box'), making the purpose immediately understandable. It distinguishes from siblings like box_folder_copy_tool (which copies rather than moves) and box_folder_info_tool (which retrieves information). However, it doesn't explicitly mention what 'move' entails in Box's context (e.g., whether it preserves metadata or permissions).

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

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

No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention when to choose box_folder_move_tool over box_folder_copy_tool (for relocating vs. duplicating) or box_file_move_tool (for moving files instead of folders). There's also no mention of prerequisites, such as needing appropriate permissions or avoiding moving folders to restricted locations.

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