Skip to main content
Glama
java-jaydev

mybox-mcp

by java-jaydev

mybox_create_folder

Create a folder in a NAVER MYBOX drive and return its ID; set a parent folder or omit it to place it at the drive root.

Instructions

Create a folder and return its id.

Args: name: Folder name. parent_id: Parent folder id. Omit to create it at the drive root.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
parent_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses the creation behavior and the return of an id, which is helpful. But for a mutation tool with zero annotation coverage, it doesn't mention permission requirements, idempotency (what happens if the folder already exists), or any failure modes.

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

Conciseness5/5

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

The description is extremely compact: one sentence stating purpose and return, followed by structured param docs. Every line earns its place and the key info (return id) is front-loaded.

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

Completeness3/5

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

An output schema exists, so the description needn't explain the return structure, only that an id is returned, which it does. However, for a mutation tool with no annotations, missing details like idempotency or required permissions leave gaps in a caller's understanding.

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

Parameters3/5

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 documents both parameters semantically: 'name' as the folder name and 'parent_id' with explicit behavior when omitted. This is useful, but it doesn't add type/format constraints beyond the schema, so it's adequate but not rich.

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

Purpose5/5

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

States a precise verb + resource ('Create a folder') and adds the return value ('return its id'). It is clearly distinguishable from siblings like mybox_upload or mybox_list, which operate on files or read state.

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

Usage Guidelines3/5

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

The parent_id guidance ('Omit to create it at the drive root') implies default behavior, giving some contextual guidance. However, there is no explicit when-to-use vs when-not, nor any reference to alternatives among the sibling tools.

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