update_onedrive_fileUpdate a OneDrive item: rename (name) and/or move it into a folder (moveToFolderId). Pass fileId (from list_onedrive_files). To remove an item, use delete_onedrive_file.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | new name | |
| fileId | Yes | the OneDrive item id | |
| moveToFolderId | No | folder id to move the item into (from create_onedrive_folder / list_onedrive_files) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the description's burden is lower. The description adds the scope of mutation (rename and/or move) and clarifies that removal is not part of this operation, which is useful behavioral context beyond the annotations. It does not describe edge cases or side effects, but given the annotation coverage, this is adequate.
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 two concise sentences, front-loaded with the primary actions and includes the essential pointer to the delete tool. Every sentence earns its place with no redundancy or filler. Ideal structure for agent consumption.
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 mutation tool with three parameters and no output schema, the description covers everything an agent needs: what it does, how to obtain the required fileId, the optional parameters, and the alternative for deletion. Annotations cover idempotency and safety, so nothing is missing 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 coverage is 100%, so the schema describes all three parameters. The description goes beyond by explaining the purpose of name and moveToFolderId ('rename (name) and/or move it into a folder'), and specifies that fileId comes from list_onedrive_files, adding a source that the schema does not have. This enriches the parameter 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?
The description clearly states the tool's action: 'Update a OneDrive item: rename (name) and/or move it into a folder (moveToFolderId).' It names the specific resource (OneDrive item) and the two possible operations, distinguishing it from deletion by pointing to delete_onedrive_file. This is precise 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 the agent when not to use this tool ('To remove an item, use delete_onedrive_file') and instructs to pass fileId from list_onedrive_files, providing a source for the parameter. It does not contrast with other update tools (e.g., update_drive_file), but the tool name and domain specificity (OneDrive) make the distinction clear enough. This is solid usage guidance for the intended scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
With 293 tools, the surface is enormous and many tools have overlapping purposes—multiple posting tools (post_to_meta, post_to_linkedin, schedule_post, etc.), multiple analytics tools per channel, and several search tools (search_meta_ads, search_instagram, search_reddit...). While each description is detailed, the volume makes it difficult for an agent to reliably distinguish between similar tools without careful reading, leading to frequent misselection.
The naming is largely consistent with a verb_noun pattern (post_to_*, list_*, create_*, delete_*, update_*, manage_*). There are clear families for major operations. A few outliers like 'google_business_account', 'hermoso_capabilities', and 'store_get' break the pattern, but the overwhelming majority follow a predictable structure, making navigation somewhat easier.
293 tools is far beyond any reasonable scope for a single MCP server, even for a comprehensive marketing platform. The calibration guide flags 50+ as an extreme mismatch, and this is nearly six times that threshold. Such a large surface overwhelms context windows, increases the probability of misselection, and makes it impractical for agents to learn or use effectively.
The tool set covers a vast domain: ad creation and rendering, posting across nine+ social channels, analytics and reporting, file management (Drive/OneDrive), competitor research, brand management, and more. It appears to provide CRUD and lifecycle coverage for most resources. While there may be minor gaps given the immense scope, the overall coverage is impressively comprehensive.