Skip to main content
Glama
Sign In
dotbugi-mcp

dotbugi-mcp

by hs-shell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

저장 위치 변경

set_storage_dir
Destructive

Changes where lecture materials, assignment attachments, and STT results are saved, under your home folder or Google Drive My Drive, with user approval and optional migration of existing files.

Instructions

강의자료·과제 첨부·STT 결과의 저장 위치를 바꾼다 (예: "자료는 문서/돋부기에 저장해줘" → path "~/Documents/돋부기"). 홈 폴더 또는 Google Drive "내 드라이브"(find_google_drive) 아래의 일반 폴더만 된다 (링크·숨김·시스템 폴더, 지금 위치의 안쪽·상위 폴더는 거부). WSL 에서는 C:\Users<사용자>... 도 된다. 위치 변경은 항상 사용자가 클라이언트 확인 창에서 직접 승인해야 한다. moveExisting(기본 true)이면 기존 자료도 새 위치로 옮긴다 (다른 드라이브면 복사·검증 후 원본 삭제). 확인 창이 없는 클라이언트면 목록과 confirmToken 을 돌려준다 — 사용자에게 보여주고 동의를 받은 뒤에만 그 토큰으로 다시 호출한다.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "set_storage_dir"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYes새 저장 위치. 절대 경로 또는 ~/ 로 시작 (WSL 은 C:\Users\... 도 가능)
confirmTokenNo확인 창을 띄울 수 없는 클라이언트에서 첫 호출이 돌려준 일회용 확인 토큰. 사용자에게 목록을 보여주고 동의를 받은 뒤에만 넣는다
moveExistingNo기존 자료를 새 위치로 옮길지 (사용자 승인 필요)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=false), the description discloses that user approval in a client confirmation dialog is always required, that moveExisting defaults to true and relocates existing data, and that cross-drive moves copy, verify, then delete the original. The two-step confirmToken flow is spelled out, including that the token must only be used after the user has seen the list and consented.

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

Conciseness4/5

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

Roughly four dense sentences, front-loaded with the action and its example, then constraints, then the confirmation/token protocol. Every sentence carries operational content, though the parenthetical example and folder-rejection list make it slightly heavy compared to an ideal minimal definition.

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

Completeness5/5

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

For a destructive mutation with no output schema, the description covers what is affected, what gets moved or deleted, permission/folder constraints, and the full approval and token round-trip. Nothing an agent needs in order to invoke it safely and correctly is missing.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description adds real meaning: the path example mapping (“자료는 문서/돋부기에 저장해줘” → ~/Documents/돋부기), the WSL C:\Users\... form, the default-true semantics of moveExisting, and the one-time nature and required user-consent precondition of confirmToken.

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 specific verb (change/set) plus the resource and even enumerates the affected data (lecture materials, assignment attachments, STT results), with a concrete example utterance mapping to a path. It is clearly the write-side counterpart to siblings like get_storage_dir and find_google_drive, so an agent can distinguish it without opening the schema.

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

Usage Guidelines4/5

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

Gives explicit when-not conditions: only plain folders under home or Google Drive My Drive, rejects symlinks/hidden/system folders and the current location's sub- or parent folders, and notes WSL support for C:\Users\... paths. It also prescribes the confirmToken fallback flow for clients without a confirmation dialog. It does not explicitly name the read sibling as the inspection alternative, so it falls just short of a 5.

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

Deploy Server

Other Tools