Aladin Book Search MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. Each tool targets a specific resource or action: bestsellers, blogger bestsellers, book details, editor choices, new books, popular categories, special new books, book search, and category search. The descriptions reinforce distinct use cases, making misselection unlikely.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout, all using snake_case. Each name starts with a verb (get_ or search_) followed by a noun, making the set predictable and readable. There are no deviations in naming conventions.
Tool Count5/5
The count of 9 tools is well-scoped for a book search server, covering various aspects like bestsellers, new books, details, and searches. Each tool earns its place by addressing a specific need in the domain without being excessive or insufficient.
Completeness4/5
The tool surface is largely complete for book search and discovery, covering key operations like retrieving lists, details, and searches. A minor gap exists in update/delete operations, but these are not expected in a search-focused domain, and agents can work around this limitation.
Average 3.1/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on July 5, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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?
No annotations are provided, so the description carries full burden but adds minimal behavioral context. It mentions the platform ('Aladin') but doesn't disclose rate limits, authentication needs, pagination behavior, or what the output looks like (e.g., list of books with details). This is inadequate for a search tool with no structured safety hints.
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, efficient sentence in Korean that directly states the tool's function. It's front-loaded with no wasted words, though it could be slightly more informative without losing conciseness.
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 complexity of a search tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, output format, and differentiation from siblings, making it insufficient for an agent to use effectively without trial and error.
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%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying a general search function, which the schema already covers with 'query' and 'searchType'. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('search') and resource ('books on Aladin'), which is clear but vague. It doesn't specify what kind of search this is (e.g., full-text, filtered) or how it differs from siblings like 'search_categories', leaving room for ambiguity.
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. With siblings like 'get_bestsellers' or 'search_categories', there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names 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, so the description carries the full burden of behavioral disclosure. It only states the basic action (retrieve detailed information using ISBN) without mentioning any behavioral traits such as error handling (e.g., what happens if the ISBN is invalid), response format, rate limits, authentication needs, or whether it's a read-only operation. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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, clear sentence that efficiently conveys the core purpose without any wasted words. It's front-loaded with the essential information (using ISBN to retrieve detailed book info), making it highly concise and well-structured for quick understanding.
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 (a read operation with one parameter) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, the response format, or any behavioral aspects like error conditions. For a tool that likely returns structured data, more context is needed to guide the agent effectively.
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 description coverage is 100%, with the parameter 'isbn' fully documented in the schema as '도서의 ISBN (10자리 또는 13자리)' (book's ISBN, 10 or 13 digits). The description adds no additional semantic information beyond what the schema provides, such as examples or edge cases. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 purpose: 'ISBN을 이용해 도서의 상세 정보를 조회합니다' (Retrieve detailed book information using ISBN). It specifies the verb ('조회합니다' - retrieve) and resource ('도서의 상세 정보' - detailed book information), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_books' or 'get_new_books', which might also retrieve book information but with different scopes or filters.
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 sibling tools like 'search_books' (for broader searches) or 'get_new_books' (for recent releases), leaving the agent to infer usage based on the tool name alone. There's no explicit context, exclusions, or prerequisites stated.
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 full burden for behavioral disclosure. It mentions the prioritization of higher-level categories, which is useful context, but fails to describe important behaviors like whether this is a read-only operation, what the return format looks like, whether results are paginated, or any rate limits. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.
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 extremely concise - just two sentences that directly state the tool's function and a key behavioral characteristic. Every word serves a purpose with zero redundancy or unnecessary elaboration.
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?
For a search tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the search results look like, how they're structured, whether there's pagination, or what happens when no matches are found. The prioritization hint is helpful but doesn't compensate for missing behavioral and output 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%, so the schema already fully documents both parameters. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation solely through the schema, with no value added by the description.
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 ('search') and resource ('Aladin book categories'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_popular_categories' or 'search_books', which would require more specific scope definition.
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 minimal guidance - it mentions that higher-level categories are prioritized, but offers no explicit when-to-use advice, no exclusions, and no comparison to alternatives like 'get_popular_categories' or 'search_books'. The agent must infer usage context from the tool name 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, so the description carries the full burden. It mentions retrieval and category filtering but fails to disclose critical behavioral traits such as whether this is a read-only operation, rate limits, authentication needs, pagination behavior (implied by 'start' and 'maxResults' but not explained), or what the return format looks like (no output schema).
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 concise with two sentences that are front-loaded and to the point. However, it could be slightly more structured by explicitly separating purpose from usage context.
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 no annotations and no output schema, the description is incomplete. It covers the basic purpose and hints at category usage but lacks details on behavioral aspects, return values, error handling, or how it differs from sibling tools, leaving significant gaps for an AI agent.
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%, so the schema fully documents parameters like 'categoryId', 'maxResults', and 'start'. The description adds marginal value by mentioning category-based search, aligning with 'categoryId', but does not provide additional semantics beyond what the schema already covers.
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 verb '조회합니다' (retrieve) and resource '알라딘 주목할 만한 신간 리스트' (Aladin notable new books list), making the purpose explicit. It distinguishes from siblings like 'get_new_books' by specifying '주목할 만한' (notable/worthy of attention), though this distinction could be more precise.
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 retrieving notable new books by category, but does not explicitly state when to use this tool versus alternatives like 'get_new_books' or 'get_bestsellers'. It mentions category-based search but lacks guidance on exclusions or prerequisites.
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 mentions that only domestic books are retrievable and category-based search is possible, which adds some behavioral context. However, it lacks details on permissions, rate limits, pagination behavior (implied by 'start' parameter but not explained), error conditions, or what the output looks like. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 concise with two sentences that efficiently convey key information: what the tool does and its main constraints. It's front-loaded with the primary purpose. There's no wasted text, though it could be slightly more structured for clarity.
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?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and some constraints, but lacks details on output format, error handling, or deeper behavioral traits. Without annotations or output schema, the agent has insufficient information to fully understand the tool's behavior and results.
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 all parameters well-documented in the schema itself (e.g., 'categoryId' for limiting search to a specific category, 'maxResults' for maximum results, 'start' for starting number). The description adds minimal value beyond the schema, only implying category-based search without providing additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('조회합니다' - retrieves/views) and resource ('알라딘 블로거 베스트셀러 목록' - Aladdin blogger bestseller list). It distinguishes this tool from siblings like 'get_bestsellers' by specifying it's specifically for 'blogger' bestsellers, though it doesn't explicitly contrast with all alternatives. The purpose is specific but could be more differentiated.
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 provides some context about when to use it ('국내도서만 조회 가능하며, 카테고리별로 검색할 수 있습니다' - only domestic books can be retrieved, and can search by category), which implies usage scenarios. However, it doesn't explicitly state when to choose this tool over alternatives like 'get_bestsellers' or 'get_editor_choice', nor does it mention any exclusions or prerequisites beyond the domestic book limitation.
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 the tool retrieves data ('조회합니다') but doesn't describe what '전체 리스트' (full list) entails (e.g., pagination, sorting, or freshness criteria), nor does it address potential limitations like rate limits or authentication requirements. The description is minimal and lacks behavioral details beyond the basic operation.
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 extremely concise with just two sentences that directly state the tool's purpose and key capability. Every word earns its place, and it's front-loaded with the core functionality. There's no wasted text or redundancy.
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 incomplete for a tool with three parameters. It doesn't explain what the tool returns (e.g., book details, pagination info), behavioral aspects like error handling, or how it differs from sibling tools. For a read operation with no structured context, the description should provide more guidance on usage and results.
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%, so the schema already fully documents all three parameters (categoryId, maxResults, start). The description adds marginal value by mentioning category-based search, which aligns with the categoryId parameter, but doesn't provide additional semantics beyond what the schema descriptions offer. This meets the baseline for high schema coverage.
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 verb ('조회합니다' - retrieve/query) and resource ('알라딘 신간 전체 리스트' - Aladin new books full list), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_special_new_books' or 'get_bestsellers' beyond mentioning it retrieves the 'full list' of new books.
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 context by stating '카테고리별로 검색할 수 있습니다' (can search by category), suggesting this tool is for browsing new books with optional category filtering. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'get_special_new_books' or 'search_books', nor does it mention any prerequisites or exclusions.
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 full burden for behavioral disclosure. It mentions the tool retrieves frequently used categories and displays top-level ones first, which provides some behavioral context. However, it doesn't address important aspects like whether this is a read-only operation, what authentication might be needed, rate limits, or what format the results will be in. For a tool with zero annotation coverage, this is insufficient behavioral transparency.
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 extremely concise - just two short sentences that communicate the essential information. Every word earns its place, with no redundant information. The structure is front-loaded with the main purpose, followed by a behavioral detail about display priority. This is an excellent example of efficient description writing.
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?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description provides adequate but minimal context. It explains what the tool does and a key behavioral aspect (top-level priority), but doesn't address what the output looks like or any operational constraints. For such a simple read operation, this is minimally viable but could benefit from more complete behavioral context.
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 description doesn't mention any parameters, but with 100% schema description coverage and only one optional parameter (limit with clear documentation), this is acceptable. The schema fully documents the single parameter with description, type, constraints, and default value. Since there are no parameters that need semantic explanation beyond what the schema provides, a score of 4 is appropriate for this simple case.
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 ('조회합니다' - retrieves) and resource ('자주 사용되는 주요 카테고리 목록' - frequently used main category list), making the purpose understandable. It distinguishes from siblings by focusing on categories rather than books or search functionality. However, it doesn't explicitly differentiate from 'search_categories' which might also retrieve categories.
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 minimal usage guidance - only mentioning that it displays top-level categories first. There's no explicit guidance on when to use this tool versus alternatives like 'search_categories' or other sibling tools that retrieve different types of data. No prerequisites, exclusions, or comparison with alternatives are provided.
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 describes a read operation ('조회합니다'), which is clear, but lacks details about rate limits, authentication requirements, pagination behavior (beyond the 'start' parameter), or what the return format looks like. For a tool with 3 parameters and no annotations, this leaves significant behavioral gaps.
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 two concise sentences with zero waste. The first sentence states the core purpose, and the second adds key functionality (category filtering). It's appropriately sized and front-loaded, making it easy to parse quickly.
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?
Given no annotations and no output schema, the description is adequate but incomplete. It covers the basic purpose and hints at filtering, but doesn't address behavioral aspects like response format, error handling, or usage constraints. For a read-only tool with 3 parameters, it meets minimum viability but lacks depth.
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 description mentions category-based search, which aligns with the 'categoryId' parameter. However, with 100% schema description coverage, the input schema already fully documents all three parameters ('categoryId', 'maxResults', 'start') with clear descriptions and defaults. The description adds minimal value beyond what's in the schema, meeting the baseline for high coverage.
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 verb ('조회합니다' - retrieve/query) and resource ('알라딘 편집자 추천 리스트' - Aladdin editor recommendation list), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_bestsellers' or 'get_new_books' beyond mentioning it's specifically for editor recommendations.
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 mentions '카테고리별로 검색할 수 있습니다' (can search by category), which implies usage context for filtering. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_bestsellers' or 'search_books', nor does it mention any exclusions or prerequisites for use.
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 provided, the description carries the full burden of behavioral disclosure. It describes the core functionality well but lacks details about rate limits, authentication requirements, pagination behavior beyond start parameter, error conditions, or what the response format looks like. The description is adequate for basic understanding but misses important operational details.
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 perfectly sized at three sentences, front-loaded with the core purpose, followed by filtering capabilities, and ending with specific guidance for time parameters. Every sentence earns its place with no wasted words or redundant information.
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?
For a read-only query tool with 6 parameters and no output schema, the description provides adequate context about what the tool does and basic usage. However, without annotations and with no output schema, it should ideally describe what the return data looks like (list structure, fields included) and any important behavioral constraints. The description is complete enough for basic understanding but has gaps for full operational use.
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%, so the schema already documents all 6 parameters thoroughly. The description adds some context about the time parameters ('특정 주간을 조회할 때는 연도, 월, 주를 모두 입력해주세요'), but doesn't provide significant additional semantic meaning beyond what's already in the parameter descriptions. This meets the baseline expectation when schema coverage is complete.
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 purpose with specific verbs ('조회합니다' - retrieve/query) and resources ('알라딘 도서 베스트셀러 목록' - Aladdin book bestseller list). It distinguishes from siblings by focusing specifically on bestsellers rather than new books, editor choices, or general searches.
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 context about when to use this tool - for retrieving bestseller lists with optional category filtering and time period specification. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools (like get_new_books or search_books for different purposes).
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:

[![mcp-aladin-books-server MCP server](https://glama.ai/mcp/servers/TeeDDub/mcp-aladin-books-server/badges/card.svg)](https://glama.ai/mcp/servers/TeeDDub/mcp-aladin-books-server)

Score Badge

Copy to your README.md:

[![mcp-aladin-books-server MCP server](https://glama.ai/mcp/servers/TeeDDub/mcp-aladin-books-server/badges/score.svg)](https://glama.ai/mcp/servers/TeeDDub/mcp-aladin-books-server)

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/TeeDDub/mcp-aladin-books-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server