Loading ToolBench
Read Microsoft Loop files and workspaces through Microsoft Graph with bounded, token-efficient MCP responses.
Four tools with complete schemas, clear descriptions, and proper parameter typing. Tool names follow verb_noun pattern (getLoopBy*, list*). All parameters have descriptions and type constraints. Pagination implemented with offset/limit. Error handling returns structured JSON with error codes. Main gaps: descriptions are functional but brief (avg 80 chars, below 194-char baseline); no output schema documentation; deprecated parameter (includeText) creates confusion; no recovery guidance in error messages.
Read a Microsoft Loop file directly from its driveId and itemId.
Read a Microsoft Loop file from a OneDrive, SharePoint, or Loop app sharing URL.
Discover accessible Microsoft Loop workspaces and their driveIds.
List .loop and .fluid files recursively inside a specific drive.
Output schema not documented. LLMs cannot plan downstream calls or extract fields without knowing response structure (e.g., what fields does getLoopByShareUrl return? Is it {text, html, metadata}?).
Deprecated parameter 'includeText' creates ambiguity. Description says 'contentMode wins' but LLMs may pass both, causing confusion. Remove deprecated param or clearly document precedence in error handling.
Error messages lack recovery guidance. toolError() returns {error, code, message, status} but does not suggest next steps (e.g., 'Try listLoopContainers() to find valid driveIds').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Tool descriptions are brief (avg 80 chars vs 194-char baseline). Missing context on when to use each tool. E.g., getLoopByShareUrl vs getLoopByItemId, when should LLM pick one over the other?
listLoopContainers and listLoopFilesInDrive return paginated results but no total count or next_cursor documented. LLMs cannot determine if more results exist or how to fetch them.