velog-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation5/5
Each 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).
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.4/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![velog_ag MCP server](https://glama.ai/mcp/servers/hyungseokyoon/velog_ag/badges/card.svg)](https://glama.ai/mcp/servers/hyungseokyoon/velog_ag)

Score Badge

Copy to your README.md:

[![velog_ag MCP server](https://glama.ai/mcp/servers/hyungseokyoon/velog_ag/badges/score.svg)](https://glama.ai/mcp/servers/hyungseokyoon/velog_ag)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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