io.github.lacausecrypto/poetrydb

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation4/5
Most tools have clearly distinct purposes, but get_sonnets and get_haikus overlap with search_by_linecount since 14-line and 3-line poems are special cases. An agent might be unsure whether to use the specialized get_* tools or the more general search_by_linecount.
Naming Consistency3/5
Tool naming mixes several patterns: catalog_* (catalog_overview, catalog_category), search_by_* (search_by_author, search_by_title, etc.), list_* (list_authors, list_titles), get_* (get_sonnets, get_haikus), and random_poem (no prefix). This inconsistency can make tool selection less predictable.
Tool Count5/5
With 12 tools, the count is well within the expected range for a domain-specific server. Each tool serves a distinct function and none feels superfluous or excessive for a poetry database.
Completeness4/5
The toolset covers searching, listing, and random access, along with helpful meta-tools for discovery. Minor gaps include the lack of a direct 'get poem by ID' or 'get full poem content' endpoint, which forces reliance on search results. Overall, the surface is reasonably complete for common poetry browsing workflows.
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
- 0 commits in the last 12 weeks
- Last stable release on April 12, 2026
- 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.
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 the full burden of behavioral disclosure. 'Find' implies a read operation, but there is no mention of return format, ordering, pagination, or any side effects. The description adds only the fact that haikus are 3-line poems, which clarifies semantics but not 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?
A single, compact sentence with no filler. The core purpose and the optional filter are front-loaded. Every word earns its place; nothing extraneous.
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 simple tool, the description is minimal, but the presence of many search-related siblings (search_by_author, search_by_lines) creates ambiguity about when this specific tool is the right choice. It does not explain how it differs from a general search, nor what output to expect. An agent cannot reliably route to this tool without additional 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?
The input schema already covers the single optional parameter with a description ('Optional author name or partial author name'), giving 100% schema coverage. The tool description merely echoes 'optionally filtered by author' and adds no new meaning beyond the schema. Baseline 3 is appropriate.
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 finds 3-line poems (haikus) with optional author filtering. The verb 'Find' and resource '3-line poems' are specific enough to distinguish from get_sonnets, though it doesn't explicitly differentiate from search_by_lines or search_by_author. The purpose is unambiguous but not fully contrasted with siblings.
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 gives no guidance on when to use this tool versus alternatives like search_by_author or search_by_lines. It implies haiku retrieval but does not state when to prefer this over a broader search. No exclusions or alternative routing 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?
With no annotations provided, the description carries the full burden. It states matching behavior but does not disclose what the return value looks like (single poem vs. list), whether results are sorted, or any limitations such as number of results. The 'exact or partial' hint is insufficient for an agent to predict behavior confidently.
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 two sentences, compact and front-loaded with the core purpose. It wastes no words, though it could add a bit more detail without becoming verbose.
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 simple search tool with one parameter and no output schema, the description is minimal. It fails to explain what the tool returns, whether it returns a collection, and any edge cases like no matches. The lack of annotations and output schema makes this description insufficient for confident usage.
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 essentially restates the schema field ('Poem title or partial title') without adding new semantics such as case sensitivity, matching precedence, or format requirements. No additional value beyond the schema.
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 states a clear verb and resource ('Find a poem by title') and specifies search matching behavior ('exact or partial title matches'). It does not name a specific sibling to differentiate from, but the title-based search is distinct enough among the listed tools; however, it could be more explicit about when to prefer it over search_combined.
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 given on when to use this tool vs. alternatives like search_by_author, search_by_lines, or search_combined. The description only implies that if you have a title, you can use this, but it never mentions exclusions or when not to use it.
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 implies a read-only operation via the verb 'show' but does not clarify what format the tools/descriptions come back in, whether an invalid category yields an error, or any other behavioral traits. The description adds little beyond what a reasonable agent would guess.
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?
A single front-loaded sentence with zero wasted words. For a one-parameter tool, this length is appropriate and every word earns its place.
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 simple single-enum-parameter informational tool, the description is mostly adequate. However, with no output schema present, the description does not explain what the returned 'tools and description' output looks like, and the concept of a category (and how it maps to the three enum values) is left unexplained.
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% - the category_id parameter is fully described with an enum ('catalog, search, or discovery') and an explicit description. The tool description's phrase 'specific category' aligns with the parameter but adds no semantic value beyond what the schema already provides, 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 states a specific verb ('Show') and resource ('tools and description for a specific category'). However, it does not differentiate from the sibling 'catalog_overview', whose scope (overview of all categories vs. one specific category) is left entirely to inference.
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 catalog_overview (the natural sibling alternative), nor any context about the search/discovery/catalog categories or their relationship. There are no explicit when/when-not statements or alternative names mentioned.
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 communicates that this is a search/retrieval operation, but it does not describe the output format, whether all matches are returned, or behavior for no results. It adds little beyond the tool name itself.
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, succinct sentence that front-loads the action ('Find') and the resource ('poems'). There is no redundant information or filler; every word contributes to the core purpose.
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 single-parameter search tool, the description is minimally adequate: the schema documents the parameter fully and the tool name plus description imply the return value. However, the lack of disambiguation from search_by_lines and the absence of any output/return details leave notable gaps for an agent, especially without annotations or an output schema.
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%, and the schema already explains that 'linecount' is an exact number of lines. The description's phrase 'specific number of lines' adds no extra meaning beyond the schema, 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 uses a clear verb ('Find') and resource ('poems') with an explicit attribute ('specific number of lines'), so the tool's purpose is understandable. However, it does not differentiate itself from the sibling tool search_by_lines, which could easily be confused with it.
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 about when to use this tool versus search_by_lines or search_combined. The description implies a line-count lookup but does not state exclusions, prerequisites, or alternatives, leaving the agent to guess.
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 action and gives no information about output format, error handling, pagination, rate limits, or any side effects. This is a significant gap for an agent to call it confidently.
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 concise sentence with no unnecessary words, and the core purpose is front-loaded. It is appropriately brief, though it sacrifices detail for brevity.
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 combined search tool with no output schema and no annotations, the description is incomplete. It does not explain how fields and values correlate (semicolon-separated values matching comma-separated fields), nor does it describe the return format. An agent would need to infer the query structure from the schema alone, which is risky. More context like examples or result handling is needed.
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%, so parameters are fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 without adding extra value.
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 it runs a combined search across multiple fields, which distinguishes it from the single-field sibling tools like search_by_author and search_by_title. The verb 'Run' and resource 'combined PoetryDB search' are specific, though it doesn't name an alternative directly.
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 multiple search fields are needed, which differentiates it from single-field siblings. However, it provides no explicit guidance on when to choose this tool over others, nor does it mention any 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 bears full responsibility. It only says 'list all poem titles', implying a read-only operation, but does not disclose whether results are paginated, limited, or sorted, nor what the return format is (e.g., array of strings). For a potentially large dataset, this is a notable gap for a tool with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, perfectly concise and free of any filler. It communicates the purpose with minimal wording and does not include redundant details.
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 zero-parameter list operation, the description is adequate but not complete. It lacks any mention of output structure, potential large result sets, or whether the list is alphabetically ordered. These details would help an agent anticipate the response, but the core functionality is clear.
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, so the schema is already comprehensive. The description adds no parameter information, but nothing is needed. Baseline 4 applies since there are no parameters to elaborate on.
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 states a clear verb 'list' and a specific resource 'all poem titles in PoetryDB'. It is unambiguous and distinct from siblings like search_by_title (which filters) or list_authors (which lists authors). No further clarification needed.
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 choose this tool over siblings. It does not mention that it returns the entire set of titles, contrast with search_by_title for filtered queries, or note any pagination or size concerns. An agent must infer usage from the 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention 'exact or partial author matches,' which is a useful trait beyond the schema. However, it omits critical behavior such as output format, default fields when 'fields' is not provided, pagination/limits, case sensitivity, and behavior when no matches are found. For a search tool, these are significant gaps that could mislead an agent about the response structure.
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?
Two sentences with no fluff. The core purpose is front-loaded, and the partial-match detail is the only non-essential addition, which is still valuable. Perfectly concise for the information conveyed.
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 simple search tool with only 2 well-documented parameters, the description is mostly adequate: it tells the agent the core query mechanism. However, it lacks details about the response shape (since no output schema exists) and does not mention whether results are limited or how the optional 'fields' parameter affects output. Given the many sibling search tools, a few more sentences about expected behavior would round it out.
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%: both parameters have descriptive text ('Author name or partial name' and 'Optional output fields...'). The description adds no extra meaning beyond the schema; it only reiterates the partial-match behavior already in the schema. Per baseline for high coverage, this is a 3.
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 is explicit: verb 'find' + resource 'poems by author name' plus matching behavior ('exact or partial'). This clearly distinguishes it from sibling search tools like search_by_title or search_by_lines, which target different criteria. No ambiguity remains.
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 purpose itself implies the use case (searching by author), but there is no explicit guidance on when to choose this tool over alternatives, nor any mention of exclusions (e.g., 'if you know the title, use search_by_title'). While the description is self-sufficient for identifying the right tool, the lack of explicit routing to siblings leaves this dimension at a baseline level.
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 carries the behavioral burden. It implies a read-only lookup via 'Find' and accurately describes the core behavior, but it does not disclose return shape, result format, matching semantics, or any limitations. This is adequate for a very simple lookup but not richly transparent.
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?
One short, front-loaded sentence with no filler. Every word earns its place and the key behavior plus optional filter are stated immediately.
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?
For a one-parameter, read-only tool with no output schema, the description plus schema is largely sufficient to make a correct call. It lacks sibling differentiation and behavioral nuance, but nothing essential to a basic invocation is missing.
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 fully describes the only parameter, 'author', as optional and accepting partial names. The description adds little beyond saying the results are filtered by author, so the schema already carries the parameter-meaning burden.
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 ('Find'), the resource ('14-line sonnets'), and the optional author filter. It is specific enough to distinguish from haiku-finding tools like get_haikus, though it does not explicitly distinguish itself from author or line-count search siblings.
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: use this when you want 14-line sonnets, optionally narrowed by author. However, it never mentions alternatives such as search_by_author, search_by_linecount, or search_combined, nor does it state when this tool should be preferred over them.
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 does state the key behavioral trait of randomness, which is a defining characteristic. However, it does not disclose the return format (e.g., full text, metadata, or how poems are sampled) or any side effects, leaving some behavioral aspects ambiguous.
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 filler. It front-loads the core action and resource ('random poems') and is appropriately sized for a simple tool with one optional parameter. Every word earns its place.
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 tool with no output schema and only a single optional parameter, the description is too minimal. It does not explain what a 'poem' consists of (e.g., text, title, author), nor does it indicate whether the result is a list of strings or structured objects. An agent cannot fully anticipate the response format, which is a significant gap for effective tool 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?
The input schema for the single parameter 'count' has full description coverage (100%), so the schema fully documents the parameter's meaning and constraints. The description adds no additional information about the parameter, so the score is at the baseline of 3.
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 one or more random poems' uses a specific verb ('Get') and resource ('random poems'), clearly distinguishing it from sibling tools like search_by_author or get_sonnets, which are for targeted or filtered retrieval. The randomness is the key differentiating factor, making the purpose unmistakable.
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 use case: retrieving poems without any specific criteria, relying on randomness. However, it provides no explicit guidance on when NOT to use this tool (e.g., when a specific author is known) or any alternatives. Thus, usage context is implied rather than explicitly 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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the search action and gives no indication of read-only nature, potential side effects, or match semantics (e.g., exact vs. partial). This is minimal information for a search 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?
A single, clear sentence with no extraneous words. The core action and subject are 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search with no output schema, the description is mostly adequate. It doesn't mention nuances like case sensitivity or wildcard support, but these are optional for basic functionality. The tool is straightforward enough that no critical information is missing.
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 the single parameter 'text' with a description that aligns with the main description. Since schema coverage is 100%, the description adds little beyond restating the parameter's purpose, warranting the baseline score for high coverage.
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 searches for poems based on text within their lines. This is a specific verb-resource pairing and naturally distinguishes itself from sibling tools like search_by_author or search_by_title, which target different attributes.
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 use when searching by line content but does not explicitly mention when not to use it or suggest alternatives. With siblings like search_by_title and search_by_author, an agent might infer the right choice, but no direct routing guidance is provided.
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. 'Overview' and 'discover' imply a safe, read-only informational tool, but the description does not say what the response contains (e.g., a list of categories, tool names, descriptions) or any structural details. The implied non-destructive nature is helpful but the surface remains thin.
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?
Two short sentences that front-load the purpose ('Overview...') and the usage signal ('Start here'). Every word earns its place; no filler or redundancy.
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?
For a zero-parameter discovery tool with no output schema, this is adequately complete: it establishes the tool as an entry point to discover categories. It could mention the output format, but given the simplicity level, nothing critical is missing for correct invocation.
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?
Zero parameters, so the baseline of 4 applies. The description correctly has nothing to explain about parameters, and schema coverage is trivially 100% with an empty properties object.
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 states a clear, specific purpose: an overview of all PoetryDB MCP tools for discovering categories. The 'overview... discover categories' framing distinguishes it from siblings like catalog_category and the various search_* tools, though it could be slightly more explicit about what it returns.
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?
'Start here' gives a clear entry-point signal, indicating this is where an agent should begin discovery. However, it does not state when NOT to use it or name alternatives (e.g., catalog_category for specific category details). The usage context is implied 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 provided, the description carries the full burden of behavioral disclosure. It conveys a read-only, all-encompassing list operation, which is transparent enough for a trivial endpoint. However, it does not mention output shape, ordering, pagination, or any limits, leaving some behavior implicit. The one-sentence description is adequate but minimal.
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 carries meaning: it specifies the action ('List'), the scope ('all available'), and the resource ('authors in PoetryDB'). It is appropriately concise for a tool of this 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?
For a zero-parameter list tool with no output schema and no annotations, the description covers the essential facts: it lists all authors. The only minor gap is the lack of an explicit return format (e.g., an array of author name strings) and any caveats like sorting or size limits, but these are easy to infer from the tool name and description. Overall, an agent has enough information to call it correctly.
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 has 100% coverage by being empty. Per the rubric, 0 params yields a baseline of 4. There are no parameter semantics for the description to add, so no points are deducted for missing parameter details.
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 states a specific verb ('List') and a clear resource ('all available authors in PoetryDB'). This unambiguously distinguishes it from sibling tools like search_by_author (which searches for specific authors) and list_titles (which lists titles, not authors). The purpose is immediately clear without needing to open the schema.
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 gives no explicit when-to-use or when-not-to-use guidance and names no alternatives. The intended usage—when you need the full author list—is implied by the phrase 'all available authors,' but there is no direction about choosing this over search_by_author for author lookup tasks. For a zero-dependency list tool this is acceptable but not openly 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:

[![mcp-poetrydb MCP server](https://glama.ai/mcp/servers/lacausecrypto/mcp-poetrydb/badges/card.svg)](https://glama.ai/mcp/servers/lacausecrypto/mcp-poetrydb)

Score Badge

Copy to your README.md:

[![mcp-poetrydb MCP server](https://glama.ai/mcp/servers/lacausecrypto/mcp-poetrydb/badges/score.svg)](https://glama.ai/mcp/servers/lacausecrypto/mcp-poetrydb)

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/lacausecrypto/mcp-poetrydb'

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