Loading ToolBench

Reading the current corpus…

dooray-mcp MCP server · F · ToolBench

← Browse

dooray-mcp

github.com/jhl8041/dooray-mcp

MCP server for Dooray - provides tools for task management, wiki, and drive operations

2026-07-28+STDIO0 tools

0/100

Definition Quality0

Protocol Readiness0

SupportabilityNot measured-

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

Scoring was not performed

Issues (6)

HIGHresponse-shaper ↗

Output schemas not documented. No tool description specifies what fields are returned or their types. LLMs cannot plan downstream tool calls or extract nested data without inferring structure from API responses.

get-my-member-infoget-drive-listget-drive-file-listget-drive-file-metacreate-drive-folderrename-drive-filemove-drive-filecopy-drive-filedelete-drive-filedownload-drive-fileupload-drive-fileupdate-drive-filecreate-project-template

HIGHrecovery-guide ↗

No error recovery guidance in tool descriptions. When a tool fails (e.g., 'File not found'), the description does not tell the LLM what to do next or suggest recovery steps.

get-drive-file-metadelete-drive-filedownload-drive-fileupload-drive-fileupdate-drive-file

HIGHconfirmation-request ↗

Destructive/write operations (delete-drive-file, move-drive-file to trash) lack confirmation or dry-run capability. Agents can irreversibly delete files without an explicit acknowledge step.

delete-drive-filemove-drive-file

MEDIUMparam-relationships ↗

download-drive-file and upload-drive-file have complex, underdocumented parameter relationships. E.g., savePath is optional but behavior differs if it's a directory vs full path, this dependency is not explicit in the schema.

download-drive-fileupload-drive-file

MEDIUMpaginated-result ↗

Tool descriptions do not explain pagination limits. get-drive-file-list accepts page/size but no description states default limits or warns that large sizes may fail or timeout.

get-drive-file-list

MEDIUMtool-annotations ↗

No tool annotations (readonly, destructive, idempotent hints) in schema. Clients cannot automatically infer which tools are safe to retry or which modify state.

Recommendations

Document output schema for every tool. Add a 'Returns' section to each description that specifies field names, types, and what they represent. Example: 'Returns: {id: string, name: string, driveId: string, type: enum(file|folder), size: number, ...}'
Add error recovery guidance to tool descriptions. For tools that fail frequently (delete-drive-file, move-drive-file), add: 'If file not found, use get-drive-file-list to verify file exists and get its current location.'
Implement confirmation pattern for destructive tools. Before delete-drive-file or move-drive-file to trash, require an explicit 'confirm=true' parameter or return a confirmation token that must be passed in a follow-up call.
Clarify parameter dependencies in download-drive-file and upload-drive-file. Add explicit schema documentation: 'savePath can be a directory (filename auto-detected from file metadata) or a full file path. If omitted, returns base64-encoded content.'
Document pagination behavior in get-drive-file-list: 'Default page=0, size=50. Maximum size=100. Returns totalCount for planning multi-page requests.'
Add tool annotations to input schema. Extend each tool's schema with 'annotations' field containing readonly, destructive, and idempotent hints. Example: {"annotations": {"readOnlyHint": true}} for get-drive-file-list.
For tools that require discovery first (e.g., create-project-template requires projectId), add a hint in the description: 'Call get-drive-list first to find project IDs if unknown.'

Score history

Overall score trend

↓ 60 points across a rubric change (v1 → v2)

0/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-22	F	0	2026-07-28+	v2
2026-03-09	C	60	-	v1