Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dorms-mcp List my apps and show recent feedback"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
도름스(dorms.school)를 내 AI 도구(클로드 코드, 커서 등)에서 바로 쓰게 해주는 MCP 서버예요.
앱을 고치고 나서 도름스에 들어가 소식을 따로 쓰지 않아도, 코딩하던 자리에서 그대로 업데이트 소식을 올리고 피드백을 확인할 수 있어요.
도구 | 하는 일 |
| 내가 도름스에 올린 앱(공동 게시 포함) 목록과 받은 도름·댓글 수 확인 |
| 앱 업데이트 소식 올리기. 그 앱에 도름을 준 선생님들에게 알림이 가요 |
| 앱에 달린 최근 댓글 20개와 받은 도름 수 가져오기 |
Related MCP server: Hellō Admin MCP Server
dorms.school에 로그인해요.
내 프로필에서 프로필 편집을 열어요.
아래쪽 외부 연동 (API 토큰) 에서 이름을 붙여 토큰 만들기를 눌러요.
화면에 한 번만 보이는 dorms_pat_... 토큰을 복사해 두세요. (다시 볼 수 없어요. 잃어버리면 새로 만들면 돼요.)
토큰은 비밀번호처럼 다뤄 주세요. 코드나 공개 저장소에 넣지 마세요.
터미널에서 한 줄이면 끝나요:
claude mcp add dorms -e DORMS_API_TOKEN=dorms_pat_여기에내토큰 -- npx -y dorms-mcp~/.cursor/mcp.json (또는 프로젝트의 .cursor/mcp.json)에 추가해요:
{
"mcpServers": {
"dorms": {
"command": "npx",
"args": ["-y", "dorms-mcp"],
"env": {
"DORMS_API_TOKEN": "dorms_pat_여기에내토큰"
}
}
}
}claude_desktop_config.json의 mcpServers에 위 커서 설정과 같은 블록을 넣으면 돼요.
설치 후 AI에게 말로 시키면 돼요:
"도름스에 올린 내 앱 목록 보여줘"
"타이머 앱에 업데이트 소식 올려줘. 이번에 다크 모드를 추가했어"
"내 앱에 어떤 피드백이 달렸는지 확인해줘"
변수 | 설명 |
| 필수. 도름스 프로필 편집 > 외부 연동에서 발급한 |
| 선택. 기본값 |
npm run selftest서버가 뜨고 도구 3개가 보이면 SELFTEST OK가 나와요.
MIT
내 앱에 달린 최근 댓글 20개와 받은 도름 수를 가져온다. 어떤 점이 좋았는지, 어떤 개선 요청이 있는지 파악해 다음 업데이트에 반영할 때 쓴다. app_id 는 list_my_apps 로 확인한 UUID.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | 앱 UUID (list_my_apps 결과의 id) |
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 that this is a read-style operation returning 20 recent comments plus a count, but it does not describe ordering, error behavior, permissions, or response structure. Adequate but minimal.
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?
Front-loaded with the core result in the first sentence, followed by purpose and parameter source in the second. Every sentence earns its place with no filler.
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 single-parameter tool with no output schema, the description gives enough context: what will be returned, why to use it, and where to get app_id. The exact return layout is unspecified, but the high-level contents are sufficient for 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?
The schema already documents app_id as a UUID from list_my_apps, and the description largely repeats that. With 100% schema description coverage, the baseline of 3 is appropriate; the description adds no meaningful parameter semantics beyond the schema.
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?
States a specific verb and resource: it fetches the latest 20 comments and received help count for the app. This clearly distinguishes it from sibling tools like list_my_apps and post_app_update.
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?
Gives clear context for when to use it: to understand user sentiment and improvement requests for the next update. It also tells the agent that app_id comes from list_my_apps, though it does not explicitly mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
도름스(dorms.school)에 내가 올린 앱(공동 게시 포함) 목록을 가져온다. 각 앱의 id(post_app_update, get_app_feedback 에 쓰는 UUID), 이름, 받은 도름 수, 댓글 수, 마지막 업데이트 시각을 준다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it clearly indicates a read operation ('목록을 가져온다') and describes the data returned (id, name, dorms count, comment count, last update). It does not mention auth, pagination, or ordering, but for a simple 0-param list tool the core behavior is transparent.
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 entire description is one dense sentence that front-loads the action and packs in scope, output schema, and sibling-tool relationships without any filler.
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 0-parameter tool with no output schema, the description provides enough to know what the tool does and what will come back. It could add the exact response shape or ordering, but those are minor gaps given the simplicity.
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?
There are no parameters and the schema is empty, so there is nothing for the description to add about input semantics. The description instead usefully specifies what each returned entry contains, which is the relevant semantic information for this tool.
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 uses a specific verb+resource ('내가 올린 앱 목록을 가져온다') and clarifies scope (including co-published apps). It also states the returned fields and names sibling tools that consume the id, so an agent can distinguish this list tool from post_app_update and get_app_feedback.
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 implies when to use the tool by explaining that the returned id is the UUID used by post_app_update and get_app_feedback. However, it does not explicitly state when to use this tool versus alternatives or any exclusions, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
도름스에 올린 내 앱에 업데이트 노트를 게시한다. 그 앱에 도름을 준 선생님들에게 알림이 가고, 앱 카드에 '업데이트' 배지가 붙는다. app_id 는 list_my_apps 로 확인한 UUID. body 는 무엇이 새로워졌는지(1~4000자, 한국어 권장). version 은 선택(예: '1.2').
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | 업데이트 내용 (1~4000자) | |
| app_id | Yes | 앱 UUID (list_my_apps 결과의 id) | |
| version | No | 버전 표기 (선택, 예: 1.2) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to carry the safety profile, the description discloses meaningful side effects: notifications to teachers who gave 도름 for the app and the '업데이트' badge on the app card. It does not mention reversibility or ownership requirements, but for a publishing action it gives substantial behavioral context.
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?
Three dense, purposeful sentences: the main action is front-loaded, side effects follow, and parameter guidance is compact. No filler or repetition.
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 3-parameter mutation tool with no annotations and no output schema, the description covers the core behavior, side effects, all parameter semantics, and the ID source. Minor omissions like response shape or error conditions are not critical for invoking it correctly.
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 baseline is 3, but the description adds real value by explaining that app_id is the UUID from list_my_apps, body should describe what's new with a Korean recommendation, and version is optional with an example. This goes beyond the schema's short labels.
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 states a specific action ('업데이트 노트를 게시한다') on a specific resource ('도름스에 올린 내 앱'), and the side effect of an '업데이트' badge clearly distinguishes it from the read-only siblings get_app_feedback and list_my_apps.
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?
It explicitly tells the agent to obtain app_id via list_my_apps, which routes to the correct sibling for the prerequisite step. The context for when to use this tool (publishing an update note) is clear, and no competing alternative is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_app_feedbacklist_my_appspost_app_updateScored across 3 tools
Each tool has a distinct job: list_my_apps discovers apps and UUIDs, get_app_feedback retrieves detailed comments for one app, and post_app_update is the only write action. Though list_my_apps and get_app_feedback both report counts, their purposes are clearly separated by summary versus detail.
All tool names follow the same lowercase snake_case verb_noun pattern: list_my_apps, get_app_feedback, post_app_update. The verbs are consistent and the resource nouns map directly to what each tool does.
Three tools is well-scoped for a server whose purpose is the app feedback/update loop. Each tool earns its place and there is no redundant tool padding the surface.
The core workflow is covered end to end: list apps, retrieve feedback, publish an update. Minor gaps exist such as no pagination for older comments or no way to reply to feedback, but they do not break the main use case.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Deploy a GitHub repo to a live HTTPS URL from your AI tool; read logs, set variables, resize apps.
Discover, compare, and monitor 1,400+ APIs directly from your AI coding agent.
Give AI coding agents access to your Vynix visual feedback, bug reports, and AI diagnosis.
