Provides tools for interacting with Velog, a Korean blogging platform, enabling AI agents to read, search, create, edit, and delete posts, manage series and profile, and search trending posts.
Click on "Install 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., "@velog-mcp Show this week's trending posts"
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.
Velog 블로그 플랫폼용 MCP(Model Context Protocol) 서버입니다.
AI 어시스턴트를 통해 Velog 글을 읽고, 검색하고, 작성할 수 있습니다.
참고: 이 프로젝트는 Velog의 비공식 GraphQL API를 사용합니다. Velog의 공식 프로젝트가 아닙니다. 이 프로젝트는 stoneHee99/velog-mcp의 아이디어를 바탕으로 개발되었습니다.
글 조회 — 사용자의 글 목록, 상세 내용 조회
글 검색 — 키워드 기반 글 검색
트렌딩 — 인기 글 조회 (일간/주간/월간)
글 작성/수정/삭제 — 마크다운 글 작성, 관리 및 썸네일 연동
시리즈/프로필 — 시리즈 목록, 사용자 프로필 조회 및 수정
간편 로그인 — Chrome 쿠키 자동 추출로 별도 설정 없이 인증
Related MCP server: @alog-world/mcp
Antigravity의 MCP 설정 파일(mcp_config.json)에 서버를 등록합니다.
Antigravity 에디터의 Agent 사이드 패널을 엽니다.
우측 상단의 ... (더보기) 아이콘을 클릭합니다.
Manage MCP Servers를 선택한 후, View raw config를 클릭하여 설정 파일을 엽니다.
아래 설정을 추가합니다.
~/.gemini/antigravity/mcp_config.json (또는 ~/.gemini/antigravity-cli/mcp_config.json) 파일에 다음 설정을 추가합니다.
npm run build를 수행한 후, 생성된 dist/index.js 파일의 절대 경로를 지정해 줍니다.
{
"mcpServers": {
"velog": {
"command": "node",
"args": ["/absolute/path/to/velog-mcp/dist/index.js"]
}
}
}추가가 완료되면 Manage MCP Servers 메뉴에서 Refresh 버튼을 눌러 적용합니다.
읽기 전용으로 사용할 경우 추가 설정 없이 바로 사용 가능합니다.
도구 | 설명 | 주요 파라미터 |
| 사용자의 글 목록 조회 |
|
| 글 상세 조회 (본문, 댓글 포함) |
|
| 트렌딩 글 조회 |
|
| 키워드로 글 검색 |
|
| 사용자 프로필 조회 |
|
| 사용자의 시리즈 목록 조회 |
|
도구 | 설명 | 주요 파라미터 |
| Chrome 쿠키에서 토큰 자동 추출 | — |
| 새 글 작성 |
|
| 기존 글 수정 |
|
| 글 삭제 |
|
| 사용자 프로필 수정 |
|
| 로컬 마크다운 파일 직접 발행 |
|
login 도구를 호출하면:
Chrome에 이미 Velog 로그인이 되어 있으면 → 쿠키를 자동으로 읽어 즉시 완료
로그인이 안 되어 있으면 → 기존 Chrome에 새 탭으로 velog.io를 열어줌 → 로그인 후 자동 추출
추출된 토큰은 ~/.velog-mcp/tokens.json에 저장되어 다음 실행 시 자동으로 불러옵니다.
{
"mcpServers": {
"velog": {
"command": "npx",
"args": ["-y", "velog-mcp"],
"env": {
"VELOG_ACCESS_TOKEN": "your_access_token",
"VELOG_REFRESH_TOKEN": "your_refresh_token"
}
}
}
}토큰 확인: velog.io > 개발자 도구 (F12) > Application > Cookies > access_token / refresh_token
환경변수 > 저장 파일 (~/.velog-mcp/tokens.json) > 미인증 (읽기 전용)
토큰 | 유효 기간 |
| 1시간 |
| 30일 |
만료 시 login 도구를 다시 호출해주세요.
"이번 주 velog 트렌딩 글 보여줘"
"velopert의 최근 글 목록 알려줘"
"velog에 '오늘의 TIL'이라는 제목으로 글 쓰고 썸네일로 'https://example.com/thumb.png' 지정해줘"
"내 벨로그 프로필의 한 줄 소개를 '매일 성장하는 개발자'로 변경해줘"
"velog에서 TypeScript 관련 글 검색해줘"
"로컬 경로 '/Users/ddukddi/notes/my_post.md' 파일을 읽어서 Velog에 포스팅해줘"publish_local_markdown) 사용법로컬에 작성한 마크다운 파일(.md)을 읽어와서 자동으로 제목과 태그를 파싱한 뒤 Velog에 바로 게시할 수 있습니다.
게시글의 메타데이터(제목, 태그, 썸네일, 공개 여부)를 설정하기 위해 파일 상단에 YAML 형식의 Frontmatter를 추가하거나, 일반 마크다운 파일처럼 첫 번째 H1 헤더(# 제목)로 제목을 설정할 수 있습니다.
예시 1: YAML Frontmatter 적용 (권장)
---
title: "나의 첫 번째 MCP 블로그 글"
tags: [MCP, Velog, AI]
is_private: false
thumbnail: "https://example.com/thumbnail.png"
---
여기에 본문 내용을 작성합니다.예시 2: 일반 마크다운 형식
# 나의 첫 번째 MCP 블로그 글
여기에 본문 내용을 작성합니다.이 경우 제목은 나의 첫 번째 MCP 블로그 글로 설정되며 본문에서는 해당 제목 헤더가 자동으로 제외되어 깔끔하게 등록됩니다.
Antigravity 에디터 대화창 또는 MCP 클라이언트에 다음과 같이 요청해 보세요.
"로컬 경로 /Users/ddukddi/notes/my_post.md 파일을 읽어서 Velog에 포스팅해줘"
"내 마크다운 파일 /path/to/file.md 내용을 블로그 형식으로 다듬은 다음에 Velog에 발행해줘"
기능 | macOS | Windows | Linux |
읽기 (조회, 검색, 트렌딩) | O | O | O |
쓰기 (환경변수 인증) | O | O | O |
자동 로그인 ( | O | O | O |
자동 로그인은 Chrome 브라우저가 필요합니다. Windows에서는 sqlite3도 PATH에 설치되어 있어야 합니다.
git clone https://github.com/stoneHee99/velog-mcp.git
cd velog-mcp
npm install
npm run build프로필 수정 기능 추가 (update_profile): 로그인된 사용자의 이름(display_name) 및 한 줄 소개(short_bio)를 수정할 수 있는 기능을 추가했습니다. 파라미터가 생략된 경우 현재의 프로필 값을 안전하게 유지하며 업데이트합니다.
글 작성 및 수정 시 썸네일(Thumbnail) 파라미터 지원: write_post 및 edit_post 도구에 thumbnail 매개변수를 추가하여 글의 커버 이미지를 외부 URL로 바로 등록할 수 있도록 개선했습니다.
로컬 마크다운 파일 직접 발행 기능 추가 (publish_local_markdown): 로컬 경로에 있는 .md 파일을 읽어 Velog 글을 작성할 수 있는 기능을 추가했습니다. 마크다운 파일 상단의 YAML Frontmatter 정보(title, tags, thumbnail, is_private) 또는 첫 번째 H1 헤더(# 제목)를 자동으로 파싱하여 글 제목 및 태그로 연동합니다.
Velog의 비공식 GraphQL API를 사용하며, API 변경 시 동작하지 않을 수 있습니다.
이 프로젝트는 Velog와 무관한 커뮤니티 프로젝트입니다.
과도한 API 호출은 자제해주세요.
Delete a post on Velog (requires authentication)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Post ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions authentication, but omits the destructive/permanent nature, potential side effects on related data, or any confirmation requirements. This is a significant gap 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 concise sentence with no redundant words, stating the action and a key requirement.
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?
Despite the low complexity, the description lacks essential behavioral details such as irreversibility and return values. With no annotations and no output schema, the tool is insufficiently described for an agent to fully predict its behavior.
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 input schema already documents the 'id' parameter with a description, giving 100% schema coverage. The description adds no extra meaning beyond the schema, so the baseline 3 is appropriate.
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 ('Delete a post') and the target resource ('on Velog'), a specific verb+resource pair. It distinguishes from sibling tools like write_post and edit_post through the delete verb.
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 explicit guidance on when to use this tool versus alternatives is provided. The phrase 'requires authentication' implies a prerequisite but does not compare with edit_post or read_post. Usage is inferred from the operation name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an existing post on Velog (requires authentication)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Post ID to edit | |
| body | No | New body (markdown) | |
| tags | No | New tags | |
| title | No | New title | |
| url_slug | No | New URL slug | |
| series_id | No | Series ID | |
| thumbnail | No | New thumbnail image URL | |
| is_private | No | Whether the post is private |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only mentions authentication but does not disclose whether edits are partial or full replacements, how existing fields are handled, side effects, or response behavior. This is a significant gap 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, front-loaded sentence that communicates the core action and a key prerequisite with zero wasted words.
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?
Despite a complex 8-parameter schema and no output schema, the description omits critical contextual details such as return values, success/error behavior, and the effect on existing post fields. This leaves the tool under-specified for an agent to use confidently.
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?
Input schema covers 100% of parameters with meaningful descriptions, so baseline is 3. The description adds no extra parameter semantics, but the schema already documents each field clearly, so no compensation is needed.
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 'Edit an existing post on Velog' clearly states the verb (edit) and resource (post), and 'existing' distinguishes it from write_post. It is specific and unambiguous, though it could explicitly contrast with write_post or delete_post for full differentiation.
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 only a prerequisite ('requires authentication') and no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like write_post or delete_post, leaving the agent to infer usage from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a user's series list on Velog
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Velog username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavior. It only says 'Get', which implies a read-only operation, but does not mention aspects like authentication requirements, return format, ordering, or pagination. This minimal disclosure is insufficient for the agent to fully predict the tool's behavior.
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, concise sentence that conveys the core purpose without extraneous words. It is front-loaded and every word contributes meaning, making it appropriately sized for the tool's simplicity.
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?
The tool is simple (one parameter, full schema coverage), but the description lacks usage context and behavioral details beyond the basic action. Given that there is no output schema, the return format is undefined, leaving some gaps. The description is minimally viable but not fully complete.
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 has 100% coverage of the single parameter 'username' with description 'Velog username'. The description adds no extra meaning beyond this, so per the rubric, a baseline score of 3 is appropriate when schemas handle the parameter documentation.
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 'Get a user's series list on Velog' clearly states the action (get), the resource (series list), and the scope (user's). It effectively distinguishes this tool from siblings such as get_user_posts (posts vs series) and get_user_profile (profile vs series), making the purpose unambiguous.
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 direct guidance on when to use this tool versus alternatives. While the resource name implies usage for series retrieval, it does not explicitly mention alternative tools or conditions for choosing this one, leaving the agent to infer from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get trending posts from Velog
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of posts to fetch | |
| offset | No | Offset for pagination | |
| timeframe | No | Timeframe for trending | week |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Get trending posts from Velog'. It does not disclose whether authentication is required, what 'trending' means, how the response is structured, or any pagination behavior. The read-only nature is evident, but the description fails to add behavioral context beyond the verb.
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, clear sentence with no filler or redundant information. It is appropriately sized for a straightforward list operation, though it might benefit from an additional clause about the response format.
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?
With no output schema, no annotations, and a one-line description, the tool lacks sufficient contextual detail. It does not explain what 'trending' is based on, what the response looks like, or how pagination integrates with the overall API. The simplicity of the tool mitigates this, but the gaps remain significant.
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 input schema provides descriptions for all three parameters (limit, offset, timeframe), so baseline is 3. The description adds no additional semantic meaning about these parameters, but the schema descriptions are already sufficient.
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 verb 'Get' and a specific resource ('trending posts') with a source ('Velog'). It inherently differentiates from sibling tools like get_user_posts or search_posts because 'trending' defines a distinct category.
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 explicit when-to-use or alternative guidance is given. The name and description imply a use case for discovering popular content, but it does not state exclusions or recommend other tools for different types of queries (e.g., search_posts for specific searches).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of posts by a Velog user
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of posts to fetch | |
| cursor | No | Cursor for pagination (post ID) | |
| username | Yes | Velog username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic action 'Get a list' without mentioning pagination (though the schema has limit/cursor), authentication needs, sorting, or what data is returned. This is insufficient behavioral disclosure for a tool with no annotations.
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, clear sentence with no waste. It is front-loaded with the main action and resource. It earns its place without unnecessary detail.
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?
The tool has 3 parameters, no output schema, and no annotations, yet the description only provides the core action. It omits important context like how pagination works (cursor/limit), what a post object contains, or any prerequisites. Given the absence of an output schema, the description should explain return behavior, but it does not.
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 100%, as each parameter (limit, cursor, username) has a description. The tool description adds no extra meaning about parameters, but the schema already documents them well. Baseline 3 applies because the schema does the heavy lifting.
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 'Get a list of posts by a Velog user' uses a specific verb and resource, clearly indicating the tool fetches a user's posts. It distinguishes from siblings like get_trending_posts (not user-specific) and search_posts (search across posts). The scope is explicit: posts by a specific Velog user.
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 usage when you need posts by a specific user, but it does not explicitly state when to use this tool versus alternatives or provide any 'when not' guidance. No sibling tools are referenced. The purpose gives context, but the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Velog user's profile information
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Velog username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get' which implies read-only, but doesn't disclose return format, error conditions, or any side effects. This is a minimal gap for a simple getter, but still lacks transparency beyond the obvious.
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, front-loaded sentence with zero wasted words. It earns its place without unnecessary elaboration.
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?
The tool is simple (one parameter, no output schema) and the description is clear about its purpose. However, it doesn't explain what 'profile information' includes or any edge cases like non-existent usernames, which an agent might need to know for robust usage. Adequate but not complete.
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 100% (username is described as 'Velog username'). The tool description adds no parameter information beyond the schema, but since the schema fully documents the single parameter, baseline 3 is appropriate.
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 ('Get') and resource ('Velog user's profile information'), clearly distinguishing it from sibling tools like get_user_posts or read_post. The purpose is immediately obvious.
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 alternatives. It doesn't mention exclusions, prerequisites, or context where another tool would be more appropriate, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a browser to log in to Velog and save authentication tokens
| 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 behavioral disclosure burden. It explicitly mentions that a browser will be opened and that authentication tokens are saved, which are key side effects. However, it does not specify whether the tool requires user interaction or blocks until login completes, leaving a minor gap.
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 that directly states the core purpose. It contains no fluff or redundant details, making it highly concise and well-structured for quick comprehension.
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's simplicity (no parameters, no output schema), the description provides adequate context for its purpose and side effects. It could be enhanced by stating that login is a prerequisite for other tools, but this is a minor omission for such a basic operation.
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 tool has zero parameters, and the schema is empty. According to the rubric, a baseline of 4 is appropriate when there are no parameters, as there is nothing to explain. The description focuses on the action rather than inputs, which is sufficient.
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 tool's function: 'Open a browser to log in to Velog and save authentication tokens'. The verb 'log in' plus the resource 'Velog' and the specific action of saving tokens distinguish it from sibling tools like get_user_posts or write_post.
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 the tool is used to authenticate for Velog operations, but it does not explicitly state when to use it (e.g., 'before other tools') or exclude alternatives. Since no alternative login tools exist, the usage context is inferred but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a local markdown file as a Velog post (requires authentication)
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Override tags. If not provided, parsed from frontmatter. | |
| title | No | Override title. If not provided, parsed from frontmatter or first H1 header. | |
| filePath | Yes | Absolute path to the local markdown file to publish | |
| thumbnail | No | Override thumbnail image URL. If not provided, parsed from frontmatter. | |
| is_private | No | Override privacy setting. If not provided, parsed from frontmatter (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that authentication is required, but it omits critical behavioral traits such as whether publishing creates a new post or updates an existing one, how existing posts are affected, side effects, or what the response contains. This is a significant gap for a publishing action.
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, front-loaded sentence that immediately states the core action and resource. Every word earns its place, and there is no redundancy or 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?
Given the tool has 5 parameters, no annotations, and no output schema, the description is too sparse. It doesn't explain the tool's role among siblings, whether it parses frontmatter, how overrides work, or what the result of publishing is. The schema covers parameters but not the operational 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?
Schema description coverage is 100%, with each parameter already documented (e.g., filePath is 'Absolute path to the local markdown file'). The description adds no additional parameter semantics beyond 'markdown file', so the baseline of 3 applies.
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 ('Publish') and the resource ('a local markdown file as a Velog post'), making the purpose immediately understandable. However, it does not explicitly distinguish itself from sibling tools like write_post or edit_post, so it misses differentiation credit.
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?
There is no guidance on when to use this tool versus alternatives such as write_post. The only additional context, 'requires authentication', is a prerequisite rather than a usage guideline. The description does not mention exclusions, typical workflows, or decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a specific Velog post with full content, comments, and metadata
| Name | Required | Description | Default |
|---|---|---|---|
| url_slug | Yes | Post URL slug | |
| username | Yes | Velog username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. 'Read' implies a non-mutating operation, and the return content (content, comments, metadata) is stated. However, it does not disclose auth requirements, error behavior (e.g., post not found), or whether drafts are accessible, leaving important behavior unspecified.
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, front-loaded sentence with no filler. Every word earns its place, making it highly efficient and easy to parse.
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?
The tool is simple with only two well-documented params and no output schema, so the description need not be lengthy. It covers the return contents and specificity, but lacks usage alternatives and edge-case behavior, making it adequate but not thorough for an agent selecting among many siblings.
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 input schema provides 100% coverage with descriptions for both username and url_slug. The description adds no parameter-level detail beyond 'specific post', so it does not meaningfully augment what the schema already communicates.
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 (Read), the resource (a specific Velog post), and the scope (full content, comments, and metadata). This distinguishes it from sibling tools like get_user_posts or search_posts, which are list-oriented.
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 word 'specific' implies this tool is for retrieving an individual post, but the description provides no explicit guidance on when to choose this instead of get_user_posts, get_trending_posts, or search_posts. No alternatives are named or exclusions given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for posts on Velog by keyword
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results | |
| offset | No | Offset for pagination | |
| keyword | Yes | Search keyword | |
| username | No | Filter by username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the core function and adds no detail on pagination behavior, result ordering, authentication, or side effects. The description provides no insight beyond what the schema already conveys.
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, concise sentence that front-loads the action and resource. Every word contributes to the meaning with zero waste.
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 lack of annotations and output schema, the description is too sparse to be contextually complete. It doesn't explain return value structure, pagination behavior, or when to prefer this tool over siblings, leaving the agent with significant gaps.
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 describes all four parameters with 100% coverage, so the baseline is 3. The description adds nothing beyond the schema's 'keyword' description, providing no extra semantic value for parameter interpretation.
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 tool's function: searching for posts on Velog by keyword. It distinguishes from sibling tools like get_user_posts (user-specific) and get_trending_posts (trending) by focusing on keyword-based search, though it doesn't explicitly name alternatives.
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 is provided on when to use this tool versus alternatives like get_user_posts or get_trending_posts. The description doesn't mention exclusions or specific scenarios, leaving the agent to infer usage from the bare function statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the current user's profile (requires authentication)
| Name | Required | Description | Default |
|---|---|---|---|
| short_bio | No | New short bio (uses current if omitted) | |
| display_name | No | New display name (uses current if omitted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only mentions authentication; it does not describe side effects, response behavior, or whether a partial update leaves unspecified fields unchanged (though schema hints at this). 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 one sentence, front-loaded with the action, and has no filler. It is appropriately concise for the tool's simplicity.
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?
The tool is simple, the schema fully documents both optional parameters, and the description adds the key authentication requirement. While no output schema exists, return values are not explicitly needed. The only minor gap is not elaborating on partial update semantics, but the schema's 'uses current if omitted' covers that.
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 covers 100% of parameters with clear descriptions, so the description does not need to repeat them. Baseline 3 is appropriate because the description adds no further semantic value 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?
Description clearly states the verb 'Update' and resource 'the current user's profile', making it distinct from sibling tools like get_user_profile. Purpose is immediately obvious.
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 clear usage context by specifying 'current user' and the authentication requirement. It does not explicitly name alternatives or exclusions, but the sibling context makes the intended use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new post on Velog (requires authentication)
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Post body (markdown) | |
| tags | No | Tags for the post | |
| title | Yes | Post title | |
| url_slug | No | Custom URL slug | |
| series_id | No | Series ID to add the post to | |
| thumbnail | No | Thumbnail image URL | |
| is_private | No | Whether the post is private |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'requires authentication' but does not describe side effects, whether the post is published immediately, what the response looks like, or any irreversibility. This is a significant transparency gap 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, efficient sentence with no fluff. It front-loads the core purpose ('Create a new post on Velog') and immediately follows with the key prerequisite, making it highly concise.
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's complexity (7 parameters) and the absence of an output schema and annotations, the description is too sparse. It does not explain return values, post-creation behavior, or any constraints beyond authentication. The schema covers parameter details, but the overall context of what happens when the tool is invoked remains incomplete.
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 input schema covers 100% of parameters with descriptive text for each field, so the baseline is 3 per the rubric. The description itself adds no additional parameter meaning beyond what the schema already provides, such as relationships or constraints.
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 the specific verb 'Create' with the resource 'a new post on Velog', making the action unmistakable. It clearly distinguishes this tool from siblings like edit_post and delete_post, which modify or remove posts.
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 usage for creating new posts through the verb 'Create', and the authentication requirement is a helpful prerequisite. However, it does not explicitly identify alternatives such as edit_post for modifications or state when not to use this tool, leaving the guidance implicit rather than explicit.
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. Dates show when Glama detected each change.
v0.3.0delete_postedit_postget_series_listget_trending_postsget_user_postsget_user_profileloginpublish_local_markdownread_postsearch_postsupdate_profilewrite_postEach tool has a clearly distinct purpose: authentication, reading posts (list vs. individual vs. trending vs. search), user profile vs. series, and CRUD operations for posts and profile. Even write_post and publish_local_markdown differ in input method (manual vs. file-based).
Tool names generally follow a verb_noun pattern in snake_case, but there is a mix of 'get_' and direct verbs like 'read' and 'search'. 'login' lacks an object, and 'publish_local_markdown' is a compound phrase, yet the pattern is still predictable and readable.
With 12 tools, the set is well-scoped for a blogging platform. It covers authentication, public browsing (posts, profiles, series, search, trending), and authenticated content management (write, edit, delete, profile update, markdown publishing) without unnecessary bloat.
Core CRUD lifecycle for posts is fully covered, and user/profile/series retrieval is present. Minor gaps include no series management (create/update/delete), no comment interaction, and no explicit logout, but these are not essential for the main blogging workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
MCP server for AI dialogue using various LLM models via AceDataCloud
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hyungseokyoon/velog_ag'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
