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., "@classby-blog-mcp Create a new blog post draft about spring fashion trends with tags spring, fashion"
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.
스튜디오B(ClassBy) 블로그 글쓰기용 MCP 서버. 블로그 글 초안 작성/수정, 이미지 첨부, 네이버 블로그 글쓰기 화면에 자동으로 채워 넣는 도구를 제공합니다.
도구 | 설명 |
| 새 블로그 글 초안 생성 (title, content, tags) |
| 기존 초안 수정 |
| 초안 조회 |
| 초안 목록 조회 |
| 로컬 이미지 파일을 초안에 첨부 |
| 네이버 블로그 글쓰기 화면을 Chrome으로 열기 |
| 열린 화면에 초안 제목/본문 입력 (발행은 하지 않음) |
| 자동화용 Chrome 창 닫기 |
naver_* 도구는 별도의 자동화 전용 Chrome 프로필
(~/.classby-blog-mcp/chrome-profile)을 사용합니다. 처음 실행 시 그 창에서
네이버에 한 번 로그인해두면 이후에도 로그인이 유지됩니다.
Related MCP server: korean-keyword-mcp
npm install
npm run build # src/ -> dist/ 복사 + dist/build.json 버전 번호 기록npm pack 실행 시 prepack 스크립트가 자동으로 npm run build를 실행하므로,
배포용 tgz에는 항상 최신 dist/가 포함됩니다.
Claude 설정 파일의 mcpServers에 아래와 같이 등록합니다 (경로는 실제 설치 위치로 교체).
npx가 아니라 node로 직접 실행해야 Windows에서 안정적으로 동작합니다.
{
"mcpServers": {
"classby-blog-mcp": {
"command": "node",
"args": ["/absolute/path/to/.classby-blog-mcp/node_modules/classby-blog-mcp/dist/server.mjs"],
"env": {
"STUDIOB_GATE_URL": "https://tool.classby.kr",
"STUDIOB_KEY": "<설치 키>"
}
}
}
}src/lib/gate.mjs에 호출 구조만 만들어 두었습니다. 실제 엔드포인트 경로, 요청/응답
필드, 실패 시 정책(도구 차단 여부 등)이 정해지면 해당 파일의 TODO 부분만 채우면
됩니다. 현재는 값이 없거나 호출이 실패해도 서버 기동을 막지 않습니다.
naver_fill_editor의 선택자는 네이버 스마트에디터 ONE 기준 추정치이며, 에디터
업데이트에 따라 조정이 필요할 수 있습니다.
글 발행(공개)은 자동화하지 않습니다 — 사용자가 직접 최종 확인 후 발행해야 합니다.
id로 블로그 글 초안 하나를 조회합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only indicates a read operation (retrieve) without detailing side effects, permissions, or other behavioral traits.
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 description is a single sentence, efficient but lacking detail. It is not verbose, but requires more context to be fully useful.
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?
Given the simplicity of the tool (1 parameter, no output schema, no annotations), the description is still incomplete. It fails to explain parameter semantics or usage context.
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 parameter 'id' is described only as 'by id'. With 0% schema description coverage, the description fails to add meaning such as format, constraints, or examples.
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 clearly states the action (retrieve), resource (blog post draft), and method (by id). It is specific but does not explicitly distinguish from sibling tools like write_post_draft or update_post_draft.
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?
No guidance on when to use or when not. The description only implies usage when an id is available, but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
기존 블로그 글 초안의 제목/본문/태그를 수정합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| tags | No | ||
| title | No | ||
| content | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only lists updatable fields without explaining update semantics (e.g., partial vs full replacement, response behavior, or required permissions). This is insufficient for a mutation tool.
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 description is a single sentence with no extraneous words. It efficiently conveys the core action and target fields.
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?
Given the tool has 4 parameters, no output schema, and no annotations, the description is too brief. It does not explain the update effect (e.g., partial update), that the id is mandatory, or what the response contains. It is incomplete for an agent to use 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 description coverage is 0%, so the description must compensate. It names three of four parameters (title, content, tags) but not the required 'id'. No details on format, constraints, or behavior are provided. The description adds minimal value beyond the schema property names.
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 explicitly states the verb '수정합니다' (edits) and the resource '기존 블로그 글 초안' (existing blog post draft), specifying the fields title/content/tags. This clearly distinguishes it from sibling tools write_post_draft and get_post_draft.
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 provides no guidance on when to use this tool versus the sibling tools. It does not state that this is for updating existing drafts, while write_post_draft creates new ones and get_post_draft retrieves them. Usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
새 블로그 글 초안을 만듭니다 (제목/본문/태그).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| title | Yes | ||
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; description only states creation but omits important behavioral traits such as whether drafts are saved, overwritten, or require authentication.
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?
Single sentence is concise but lacks structure; no filler but also no additional information beyond what is obvious from the name.
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?
Lacks explanation of return value, side effects, or prerequisites. Given no annotations or output schema, the description is too minimal for a draft creation tool.
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 has no descriptions for parameters (0% coverage). The description only reiterates parameter names (title/content/tags) without adding constraints, format, or usage details.
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 Korean description clearly states 'creates a new blog post draft' with parameters title/content/tags, directly naming the action and resource. Sibling tools update_post_draft and get_post_draft further differentiate purpose.
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?
No guidance on when to use this tool versus updating or getting drafts. No exclusions or context provided.
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_post_draftupdate_post_draftwrite_post_draftScored across 3 tools
Each tool targets a distinct CRUD action on blog post drafts (create, update, read), with no overlapping purposes. Agents can easily distinguish them.
All tools follow a consistent verb_noun pattern: write_post_draft, update_post_draft, get_post_draft. No mixing of styles or vague verbs.
Three tools is minimal but reasonable for a focused 'draft management' scope. It could be slightly thin but still fits the purpose without excess.
The set covers create, read, and update, but notably missing delete and list operations. Agents have no way to delete drafts or view all drafts, which may cause dead ends in workflows.
Create, manage, publish, and analyze Inblog content through AI agents.
Create, edit, organize, publish, and configure JustBlogged blogs from MCP clients.
SEO, competitor and AI-search data, plus blog management — draft, schedule and publish posts.
Search, label and export your LinkedIn saved posts, then draft, schedule and publish from them.
