Skip to main content
Glama
AIDataNordic

alexandria-mcp

by AIDataNordic
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Server Quality Checklist

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

  • Latest release: v1.0.5

  • Disambiguation5/5

    Each tool has a clear and distinct purpose: listing books by metadata, searching within texts using semantic search, and testing connectivity. No functional overlap.

    Naming Consistency5/5

    All tool names follow a consistent snake_case pattern with verb_noun structure (get_book_list, search_texts) and ping as a standard connectivity verb.

    Tool Count4/5

    Three tools is a minimal but reasonable set for a focused server that provides book listing and text search. The count is slightly low but not insufficient for the domain.

    Completeness4/5

    The server covers the core functions of discovering books and searching within texts. Missing a dedicated tool for retrieving full metadata or full text by identifier, but the set is largely complete for a search-oriented server.

  • Average 4.4/5 across 3 of 3 tools scored. Lowest: 3.9/5.

    See the Tool Scores section below for per-tool breakdowns.

    • 0 of 1 community issues answered or closed in the last 6 months
    • 2 commits in the last 12 weeks
    • Last stable release on
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI is passing

  • 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.

  • This repository includes a glama.json configuration file.

  • 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.

  • View related servers

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

  • Behavior4/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that it returns a greeting and confirms the server is running, which provides additional behavioral context beyond the annotation.

    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 is concise, front-loaded, and contains no redundant information. Every word contributes to understanding.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness5/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For a simple tool with 1 optional parameter, annotations, and an output schema, the description is complete enough. It covers the purpose, behavior, and usage context without missing critical information.

    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 the parameter 'name' already described as 'Name to greet' with a default. The tool description does not add any further parameter semantics beyond the schema, so baseline score of 3 applies.

    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 tool is a 'Simple connectivity test' that 'Returns a greeting to confirm the server is running.' This is a specific verb+resource combination and distinguishes it from sibling tools like get_book_list and search_texts.

    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 implies when to use (to test connectivity) but does not explicitly state when not to use or provide alternatives. However, given the simplicity and clear distinction from sibling tools, the usage context is clear enough.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior5/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    The description adds significant behavioral context beyond the annotations (readOnlyHint, openWorldHint): it specifies the collection scope, multilingual support, reranking behavior, and result structure. No contradictions with annotations.

    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 well-structured with bullet points and sections, but it is somewhat lengthy. Every sentence contributes value, and the main purpose is front-loaded.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness5/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool has 4 parameters and an output schema, the description is comprehensive: it covers the collection size, languages, parameter examples, and return format. It leaves no important 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?

    Schema description coverage is 100%, so the baseline is 3. The description repeats some parameter info but adds value with examples and additional details (e.g., author substring matching, language codes).

    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 explicitly states the tool's purpose: searching '4.6 million classical philosophy and humanities texts from Archive.org.' It uses a specific verb ('Search') and resource, and clearly distinguishes from siblings (get_book_list, ping).

    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 context on when to use the tool (searching philosophy texts) and includes example queries. It does not explicitly state when not to use it, but the context is clear and implies usage scenarios.

    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?

    Annotations indicate readOnlyHint=true, but the description adds important behavior: 'Returns unique books (one entry per Archive.org identifier)' and 'without filters, results are arbitrary'. This goes beyond annotations and provides useful context.

    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 concise and well-structured: a brief summary followed by a parameter list and return description. Every sentence is informative, and it is front-loaded with the core function.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness5/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    The description covers the purpose, all parameters, and return fields. Given the presence of an output schema and the tool's simplicity, the description is complete and leaves no obvious gaps.

    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?

    Schema coverage is 100%, so the description's parameter details are largely redundant, but it adds helpful examples (e.g., 'Kant', 'ethics', 'eng') and clarifies case-insensitive substring matching. This adds moderate value.

    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 'List books in the Alexandria collection, optionally filtered by author, subject or language.' This is specific, with a clear verb and resource. It distinguishes from sibling tools like search_texts by focusing on metadata listing.

    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 recommends using at least one filter to avoid arbitrary results. However, it does not explicitly compare to the sibling tool search_texts, leaving some ambiguity about when to use which. Still, the guidance is helpful.

    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

alexandria-mcp MCP server

Copy to your README.md:

Score Badge

alexandria-mcp MCP server

Copy to your README.md:

Latest Blog Posts

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/AIDataNordic/alexandria-mcp'

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