5eMCP

Server Quality Checklist

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

Latest release: v1.2.0
Create a release to enable server coherence scoring.
Create a release to enable tool definition quality scoring.
- 1 of 1 community issues answered or closed in the last 6 months
- 20 commits in the last 12 weeks
- Last stable release on September 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral-disclosure burden. It states matching is by name and that a list is returned, which is useful, but it does not mention default ruleset behavior, official-vs-homebrew filtering, pagination limits, or any non-obvious search behavior. This is adequate but minimal for an unannotated 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?
Two short sentences: the first states what the tool does and returns, and the second provides usage routing. Every clause earns its place, and the most important scope information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description combined with a fully documented five-parameter schema covers the essential invocation decisions. It could be more explicit about output shape and default filtering, but those are either stated in the schema or inferable from the 'returns a list' statement. The omnisearch alternative also rounds out the decision 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 baseline is 3. The description's 'by name' aligns with the query parameter but adds no additional meaning beyond the schema for limit, fields, ruleset, or include_homebrew. The schema does the necessary work here.
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 core operation is clear: search D&D 5e sourcebooks by name and get a list of matching entries. It identifies the resource and action well enough to distinguish book_search from the many entity-specific search siblings, though the phrase 'content type' is vague and could make an agent think it searches content entries rather than book records.
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 explicitly tells the agent when to use the tool ('when you know the content type') and provides an alternative ('if unsure of the type, use omnisearch instead'). It lacks detailed exclusions against the other specialized search tools, but the routing guidance to omnisearch is actionable and clear.
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?
There are no annotations, so the description carries the behavioral disclosure burden, but it only mentions that a list of matches is returned. It does not describe partial-name matching behavior, pagination or limits, ruleset filtering, homebrew inclusion, or the absence of side effects, which an agent would want before calling.
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?
Three short sentences, front-loaded with the core action and resource, with the routing hint placed last. Every sentence earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters and no output schema, and the description provides only the most basic invocation context. The schema fills in parameters well, but the description leaves ambiguity about return shape beyond 'matching entries' and does not mention important defaults like limit or ruleset.
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 coverage is 100%, so the baseline is 3. The description only adds that search is by name, which maps to the query parameter, and does not elaborate on limit, fields, ruleset, or include_homebrew; the schema already documents those adequately.
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 and resource: search D&D 5e character classes by name, and says it returns a list of matching entries. This distinguishes it from omnisearch and from class_get-style exact lookups in the sibling list, despite the minor typo 'classs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use this tool: when the content type is known. It also names the alternative, omnisearch, for the uncertain case. This gives clear selection guidance within a large family of sibling search tools.
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?
There are no annotations, so the description carries the burden. It adds useful behavioral context by stating the return shape is a list of matching entries, and that search is by name/partial name. It doesn't disclose pagination, sorting, empty result behavior, or any error conditions, which would be expected for an unannotated 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?
Three short sentences with no filler. The core action is stated first, the return type is next, and the alternative routing is last. Every sentence earns its place and the description is easy to scan.
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?
This is a search tool with seven parameters and no output schema, so some extra context about result format or limits would help. The description explains basic selection logic and return list shape, but omits details like field meanings, pagination, or matching behavior beyond the fact that partial names are allowed. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all seven parameters including defaults and allowed values. The description adds only the general hint 'by name', which reinforces the query parameter but doesn't clarify filter semantics beyond the schema. Baseline 3 is appropriate given full schema 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 names a specific verb ('Search'), a concrete resource ('D&D 5e magic or mundane items'), and the input method ('by name'). It also distinguishes itself from the general-purpose omnisearch by limiting scope to items, and from item_get by saying it returns a list of matching entries.
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?
It explicitly states when to use: when you know the content type is an item. It also names omnisearch as the alternative when type is uncertain. However, it doesn't mention when to use item_get instead of item_search, which is a sibling tool that likely handles exact single-item lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It transparently states that the tool lists all available source abbreviations with their content types and files, and that filtering by content type is optional. For a read-only enumeration operation, this is adequate, though it does not describe output shape or any edge-case 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, front-loaded sentence with no wasted words. It states the primary action and the optional filter in a compact and readable way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has no required parameters, and the schema covers all parameters thoroughly. The description conveys the essential behavior and return contents, though it could be slightly more complete by noting the default ruleset behavior or how homebrew interacts with the source list; these are already covered by parameter descriptions.
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 provides detailed descriptions for ruleset, homebrew, and content_type. The description adds context about the output contents but does not meaningfully extend parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('available source abbreviations'), and clarifies what is included ('content types and files'). This clearly distinguishes list_sources from the many get/search sibling tools, which retrieve specific content rather than enumerate available sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to enumerate available sources, and mentions optional content-type filtering, but it does not explicitly state when to prefer this over alternatives or provide exclusions. No sibling tool is referenced, leaving the when-to-use decision mostly to inference.
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?
The description communicates the core behavior — returning status information — and lists the output categories. However, with no annotations provided, it does not explicitly state that the operation is read-only, nor does it disclose behavior around missing manifests, freshness/caching, or error conditions. The verb 'Returns' implies non-mutating behavior, but only implicitly.
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, focused sentence that leads with the verb and immediately specifies the output contents. There is no filler or repetition; every word contributes to understanding what the tool does.
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 tool with one optional parameter and no output schema, the description adequately captures the primary return information: build time, file counts, and unknown content types. It is complete enough for an agent to call the tool and interpret the general result, though it does not specify the exact JSON structure or timestamp format.
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 ruleset parameter fully documented including its enum values and default behavior. The description itself adds no parameter detail, but the schema already carries the full meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb, 'Returns', and identifies the exact resource: the manifest. It also enumerates the returned data — build time, file counts by content type, and unknown content types — making the tool's function unambiguous and distinct from the many sibling search/get tools.
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 makes clear that this tool is for querying manifest status, and no sibling tool appears to offer the same resource, so there is little ambiguity about when to use it. It does not explicitly specify exclusions or alternative tool recommendations, but the unique scope provides clear context.
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?
No annotations are provided, so the description carries the full burden. It states that the tool returns a list of matching entries and that matching is name-based, but it does not disclose behavior such as partial-match semantics, ordering, no-result behavior, or how the ruleset/homebrew toggles interact. These are mostly covered by the schema, but the description itself adds only minimal behavioral 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?
Three short sentences, with the core operation and output first, followed by routing guidance. No redundant or filler words; every sentence contributes.
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 search tool with a fully documented schema, the description covers selection (object vs omnisearch) and basic output. The lack of an output schema means return-entry shape is unspecified, but the description at least says a list of matches is returned, and the parameter details are fully in the 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?
Input schema covers 100% of the 5 parameters, so the baseline is 3. The description's 'by name' restates the query parameter's meaning and adds no additional parameter detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb ('Search'), a specific resource ('D&D 5e objects'), and a scoping method ('by name'), and the second sentence ('Returns a list of matching entries') confirms the output. The closing sentence differentiates it from omnisearch, and the resource name distinguishes it from the type-specific sibling 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 gives an explicit usage condition ('Use when you know the content type') and an explicit alternative for the uncertain case ('if unsure of the type, use omnisearch instead'). It does not explicitly point to the per-type sibling searches, but the condition plus tool name makes the intended selection reasonably clear.
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 behavioral burden. It does disclose the primary output behavior ('Returns a list of matching entries') and the search scope, but it does not explicitly state the read-only safety profile, absence of side effects, or edge behaviors such as default exclusion of homebrew. The disclosed information is useful but not rich.
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?
Three short sentences, each earning its place: purpose, behavior, and usage routing. The most decision-critical information is front-loaded, and there is zero filler or redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately states the return shape ('a list of matching entries'). Combined with full schema coverage of all parameters and explicit alternative routing to omnisearch, an agent has enough to select and call the tool correctly. Minor omissions such as sort order and pagination behavior are low-stakes gaps for a list search tool.
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 coverage is 100%, so all five parameters already carry descriptive documentation, meeting the baseline. The description's 'by name' reinforces the query parameter semantics but adds no meaning beyond what the schema provides for limit, fields, ruleset, or include_homebrew. This is an adequate but not compensating contribution.
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 ('Search'), a concrete resource ('D&D 5e published adventures'), and the matching mechanism ('by name'), then confirms the outcome ('Returns a list of matching entries'). This clearly differentiates it from the many sibling search tools by content type and from adventure_get, which retrieves a specific adventure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use direction ('Use when you know the content type') and names the alternative with its selection condition ('if unsure of the type, use omnisearch instead'). This is direct routing guidance that removes ambiguity for the agent.
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?
No annotation are provided, so the description carries the behavior disclosure burden. It does add useful behavior info—'Returns the complete entry with description merged in'—which clarifies the expected output. However, it does not say what happens when an exact name has no match, which is a relevant gap for a lookup 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?
Three short sentences, each earning its place: what it gets, what it returns, and when to prefer it over the sibling search. 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 simple exact-name getter with full schema coverage, it is mostly complete: it describes the returned entry and distinguishes from book_search. The only notable omission is not-found or error behavior, which would be useful since no output schema exists.
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 parameter semantics are already fully documented. The description reinforces the 'exact name' requirement but does not add meaning beyond the schema, matching the baseline score 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?
States a specific verbplus resource: 'Get a specific D&D 5e sourcebook by exact name.' It also distinguishes itself from the sibling book_search by saying to prefer this tool when an exact name is known, so an agent can select it correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Prefer this over book_search when you have an exact name,' which provides both the condition for using this tool and the alternative to fall back on. This is clear enough to route the agent correctly.
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 is the only source of behavioral context. It does disclose that the tool returns a list of matching entries, which is useful. However, it does not describe matching semantics (partial vs exact, case sensitivity), pagination behavior, or what happens when no matches are found, leaving some ambiguity.
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 sentences with no filler. The first sentence states the action and result, and the second provides routing guidance. Every part earns its place and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of a search tool, a 100% covered schema, and the description's clear statement of purpose and alternative routing, the definition is largely complete. It could be slightly stronger by noting that results are limited/paginated, but the schema already exposes the limit parameter and default.
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 input schema fully documents all five parameters. The description adds no extra parameter meaning beyond restating that the search is 'by name', which the query parameter already says. This meets the baseline for fully covered schemas but does not go beyond it.
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 specific action: 'Search D&D 5e condition or diseases by name' and the result: 'Returns a list of matching entries.' This is a concrete verb+resource pairing that distinguishes condition_search from the many sibling search tools and from omnisearch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: 'Use when you know the content type; if unsure of the type, use omnisearch instead.' This is a clear routing rule that names the alternative and the condition for selecting it.
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. It discloses that the tool performs a name-based search and returns matching entries, but it does not explain matching semantics, ordering, paging, or that homebrew/rulsets is a filtering concern. These are reasonable gaps for a read-only search tool, but some behavioral details are left undocumented.
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 deliver the core purpose and the essential routing guidance. There is no filler, and the most important scoping information is front-loaded before the alternative tool is mentioned.
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 search tool with five well-documented parameters and no output schema, the description adequately states that results are a list of matching entries. It does not enumerate all result fields, but the schema's 'fields' parameter plus the high-level return statement are sufficient for an agent to call the tool correctly.
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 each parameter already has a meaningful description. The tool description adds only the 'by name' behavior, which corresponds to the query parameter. Per the rubric, the baseline is 3 when the schema covers all parameters, and the description does not need to restate them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') with a specific resource ('D&D 5e deck') and an input key ('by name'). It also clarifies the output ('a list of matching entries') and gives a concrete example ('Deck of Many Things'), making the tool's purpose immediately distinguishable from the sibling search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit routing guidance: 'Use when you know the content type; if unsure of the type, use omnisearch instead.' This directly tells the agent when to choose deck_search over the broad sibling tool omnisearch, leaving little to inference.
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 behavioral burden. It accurately states that the tool searches by name and returns matching entries, which implies a read-only search. However, it does not disclose matching semantics such as partial matching, default ruleset behavior, or how results are ordered, leaving some room for misinterpretation.
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 sentences with no wasted words. The primary action and result are front-loaded, and the alternative routing is placed in the second sentence. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a search tool with fully documented parameters: it states what it searches, what it returns, and when to use an alternative. The lack of an output schema is mitigated by the explicit 'returns a list of matching entries.' It could mention result behavior like limit or default ruleset, but those are already covered in the input 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%, so the parameters are already fully documented in the input schema. The description's mention of searching 'by name' aligns with the 'query' parameter but adds little beyond what the schema already states. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Search D&D 5e deity or gods by name' and states the output shape: 'Returns a list of matching entries.' This clearly differentiates it from content-get tools and other content-type searches in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use when you know the content type; if unsure of the type, use omnisearch instead.' This names the alternative tool and gives a concrete condition for choosing between them, so an agent does not have to infer usage.
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?
No annotations are provided, so the description must carry some behavioral burden. It discloses that the tool returns a list of matching entries, which is basic but useful. However, it does not describe search semantics (e.g., partial matching, case sensitivity), filtering behavior, or what happens with no matches, though some of this is partially addressed by parameter descriptions in the 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?
Two sentences with zero waste. The core behavior is front-loaded, and the routing guidance is delivered in a compact conditional clause. Every word earns its place.
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 five-parameter search tool with no output schema and no annotations, the description plus fully documented schema covers the essential invocation context: what to search, what is returned, and when to prefer an alternative. It could mention result format or default ordering, but those are not critical for correct selection and invocation.
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 adds no parameter-level meaning beyond what the schema already documents; its 'search by name' phrasing roughly maps to the query parameter but does not elaborate on limit, fields, ruleset, or include_homebrew.
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?
States a specific action (search), resource (D&D 5e feats), and mechanism (by name), and clarifies the return type (a list of matching entries). This clearly distinguishes it from feat_get and other resource-specific searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool — when you know the content type is feats — and names the alternative (omnisearch) plus the condition for choosing it (if unsure of the type). No ambiguity remains for selection.
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?
No annotations exist, so the description carries the full burden. It discloses the basic read behavior (search by name) and the return shape (a list of matching entries), but adds no deeper behavioral context such as matching semantics, source scoping, ordering, or limits. Adequate but not rich.
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?
Three short sentences, each earning its place: purpose, return value, and usage routing. Purpose is front-loaded and there is no repetition of schema content or filler.
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 straightforward search tool this is nearly complete: the schema documents every parameter fully, and the description covers purpose, matching basis, return type, and tool selection. With no output schema, the return description is minimal but adequate; slightly more detail on result shape would push it higher.
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 all five parameters (query, limit, fields, ruleset, include_homebrew) are already documented with descriptions, defaults, and an enum. The description adds only the name-based matching hint that maps to query, so the baseline 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?
States a specific verb and resource: Search D&D 5e languages by name. The language-specific scope is unambiguous among the many sibling *_search tools, and the closing sentence explicitly differentiates it from omnisearch, so an agent can distinguish this tool without opening 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance (when you know the content type) and names the alternative with its trigger condition (if unsure of the type, use omnisearch instead). This provides clear tool-selection routing comparable to the high-quality calibration example.
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 disclosure burden. It adds useful behavior information ('Returns the complete entry with description merged in'), but it does not disclose not-found behavior, duplicate-name disambiguation nuances, or response format specifics. This is adequate but not rich.
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?
Three short sentences, each earning its place: what the tool does, what it returns, and when to prefer it. The key fact (exact name lookup) is front-loaded, and there is no 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 simple exact-name lookup with well-described parameters, the description is nearly complete: it states the resource, the matching behavior, and the return shape. Minor gaps like not-found behavior and duplicate-name disambiguation are not covered, but the absence of an output schema is partially offset by the 'complete entry' return statement.
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 describes all three parameters with 100% coverage, so the baseline is 3. The description's 'exact name' phrasing reinforces the required 'name' parameter but does not add material meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get'), a specific resource (D&D 5e monster or creature), and the exact-match lookup mode. It also explicitly differentiates this tool from monster_search by naming when to prefer it, so an agent can distinguish it from the sibling without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit routing guidance: prefer this over monster_search when you have an exact name. This directly tells the agent when to use the tool versus an alternative, leaving little ambiguity.
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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does convey that the tool is a read-only name search returning a list, but it does not mention behavior like the default return shape, the potentially large all-fields payload, or ordering/pagination traits. Basic transparency is present, but the description is thin on behavioral detail.
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 short, front-loaded with the core purpose, and contains no filler. The routing guidance earns its place in the final sentence without bloating the definition.
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 search tool with eight well-documented parameters and no output schema, the description is largely complete: it states the return kind and the key alternative. A small gap is that it does not hint at response size or the impact of the fields parameter, but the schema already covers the parameter-level details.
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 every parameter in detail. The description adds only the 'by name' framing, which modestly clarifies the query parameter, but does not go beyond the schema's existing 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 states a specific action ('Search D&D 5e monster or creatures by name') and a concrete outcome ('Returns a list of matching entries'). It also distinguishes the tool from omnisearch, making its scope immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool ('Use when you know the content type') and when not to, directing it to omnisearch instead. This is clear, actionable routing guidance.
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?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool searches by name and returns a list of matching entries, which is core behavior. However, it does not characterize matching semantics (partial/fuzzy/case-insensitive), default scoping beyond the schema, or any output shape 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?
Two concise sentences with no filler. The first sentence states the operation and resource, the second covers the result and usage guidance. Every sentence earns its place.
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?
With a rich schema covering all parameters and a clear statement that the tool returns a list of matching entries, the description is sufficient for an agent to select and invoke the tool correctly. It could add more detail about the returned entry shape, but this is a moderate gap given the straightforward search nature and the schema's completeness.
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 five parameters. The description adds no additional parameter meaning, which meets the baseline for full schema coverage but does not exceed it.
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 ('Search'), a specific resource ('D&D 5e optional class feature or invocations'), and the search key ('by name'). It also names the omnisearch sibling as the alternative for uncertain content types, which helps distinguish it from the many other search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool ('Use when you know the content type') and when to use an alternative ('if unsure of the type, use omnisearch instead'). This gives an agent a clear decision rule with minimal inference.
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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states that the operation is a search and returns a list of matching entries, which implies read-only behavior. However, it does not disclose matching semantics (case sensitivity, partial vs. exact) or any potential side effects beyond what the schema already suggests. Some details are in the schema (e.g., 'Name or partial name'), but the description itself is 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 appropriately sized: three short sentences. The core purpose is front-loaded, the return format is stated, and the usage alternative is provided at the end. No unnecessary details or repetition.
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 search tool with five well-documented parameters, the description is largely complete: it identifies the target resource, the input method (by name), and the output shape (a list). It could go slightly further to explicitly mention the read-only nature or default behavior, but since no output schema exists, stating the return type is important and helpful. The absence of a psionic_get sibling makes the list output sufficient for an agent to understand the response.
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 adds no parameter-specific meaning beyond the schema; it only mentions 'by name', which is already captured by the query parameter description. The schema already documents limit, fields, ruleset, and include_homebrew adequately.
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 states a specific verb and resource: 'Search D&D 5e psionic power or disciplines by name.' This clearly distinguishes it from sibling search tools like spell_search, monster_search, and omnisearch. The phrase 'Returns a list of matching entries' reinforces its purpose as a search/list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: 'Use when you know the content type.' It also provides the alternative for uncertain cases: 'if unsure of the type, use omnisearch instead.' This is clear, actionable routing guidance with no ambiguity.
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. It discloses that the tool searches by name and returns a list of matching entries, which conveys a read-only, non-mutating behavior. However, it does not mention search semantics such as partial matching, ordering, default ruleset behavior, or whether homebrew is excluded by default, though some of these are implied by the 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?
Two sentences, front-loaded with the core purpose, and no filler. The usage guidance is delivered efficiently after the primary statement.
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 search tool with 5 parameters fully documented in the schema, the description provides enough context: what it searches, what it returns, and when to use an alternative. The lack of an output schema is mitigated by the clear 'returns a list of matching entries' statement, though richer detail on result ordering or empty-result behavior would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even without extra parameter detail in the description. The description adds the 'by name' semantic for query, which is useful, but it does not meaningfully expand on the other parameters beyond what the schema already documents.
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 and resource: 'Search D&D 5e supernatural gift or boons by name.' It also distinguishes the tool from the generic omnisearch sibling by noting the content-type-specific scope, so an agent can tell it apart without inspecting 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('when you know the content type') and when to use the alternative instead ('if unsure of the type, use omnisearch instead'). This is clear routing guidance that leaves little to inference.
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?
No annotations are provided, so the description carries the behavioral burden. It discloses that this is a name-based search returning matching entries, which is useful, but it does not describe matching behavior (e.g., fuzzy vs. exact), data source caveats, or other behavioral nuances. For a read-only search tool this is adequate but not rich.
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 tight sentences with no filler. The core action and scope are front-loaded, and the usage guidance is delivered efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple search operation with well-documented parameters and a clear routing rule to omnisearch. The lack of an output schema means the description could say a bit more about return structure, but 'list of matching entries' is sufficient for this low-complexity tool.
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 all five parameters. The description only reinforces that searching is by name and adds no additional meaning beyond the schema, which is acceptable given the high schema 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 action ('Search D&D 5e sense ... by name'), the resource type ('sense'), and the expected output ('a list of matching entries'). The examples 'darkvision, tremorsense' further disambiguate it from sibling search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: use this tool when the content type is known, and use omnisearch when unsure. This directly addresses tool selection among the many sibling search tools.
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?
No annotations are provided, so the description carries the full burden. It discloses the basic outcome ('Returns a list of matching entries') and scoping ('by name'), implying a read-only search. However, it does not state whether the search is exact/partial, whether official-only by default, or any result-shape details beyond a list. This is minimally adequate but not rich.
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 zero waste. The core scope and return type are front-loaded, and the alternative routing is given in the second sentence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, what it returns, and when to use it (plus the omnisearch fallback). The schema supplies all parameter semantics. Since there is no output schema, a slightly more explicit return shape would be ideal, but 'a list of matching entries' is sufficient for a search tool.
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% — all five parameters have descriptions, defaults, and constraints. The description adds no param-level detail, but the schema already handles it, so baseline 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 states a specific verb ('Search'), resource ('D&D 5e random tables'), and method ('by name'). It explicitly names omnisearch as the alternative, and 'random tables' clearly separates it from the many content-type search siblings like spell_search, monster_search, and item_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit decision rule: 'Use when you know the content type; if unsure of the type, use omnisearch instead.' This directly tells an agent when to invoke this tool and when to choose a sibling tool, leaving no inference required.
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?
No annotations are present, so the description carries the behavioral disclosure burden. It does disclose that the result is a list and that matching is by name. However, it does not mention default ruleset behavior, homebrew inclusion, or partial-match semantics beyond what the schema already states. This is adequate but has clear 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 short sentences with no filler. The core action and resource are front-loaded, followed by the return shape and a concise routing rule.
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 search tool, the description covers purpose, usage conditions, and return shape. Optional parameters are fully documented in the schema. The lack of an output schema means exact result fields are not described, but the 'fields' parameter and the generic 'list of matching entries' statement make this largely sufficient.
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 five parameters. The description only reinforces that 'query' is a name or partial name; it 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search'), a specific resource category ('D&D 5e trap or hazards'), and a matching mode ('by name'). It also states the return shape ('a list of matching entries'), which distinguishes it from single-result get tools and from the broader omnisearch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use this tool: when the content type is known. It also names the alternative (omnisearch) and the condition for choosing it ('if unsure of the type'), giving a clear when/when-not decision rule.
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?
No annotations are provided, so the description carries the full behavioral burden. It discloses that this is a read-style search that returns a list, ruling out mutation, but it does not clarify matching behavior, edge cases, or output structure beyond that. For a non-destructive search tool this is adequate but not rich.
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 filler: the core action comes first, the return behavior second, and the routing guidance last. Every clause contributes to selection or invocation.
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 five-parameter search tool with no output schema and no annotations, the description supplies the essential selection cue, the search scope, and the return shape. It stops short of describing result fields or edge-case behavior, and since there is no output schema, a small completeness gap remains.
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 query, limit, fields, ruleset, and include_homebrew. The description only reinforces 'by name,' which aligns with query but adds no new parameter-level meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search'), resource ('D&D 5e variant rules'), and scope ('by name'), followed by what it returns. The closing sentence distinguishes it from omnisearch, and the tool name distinguishes it from the other typed content searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool—when the content type is known—and provides the alternative, omnisearch, for uncertain cases. This gives an agent clear routing guidance without needing to inspect sibling schemas.
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 full behavioral burden. It states that the tool returns a list of matching entries, which is useful, but it does not disclose any additional behavior such as partial matching details, default ruleset behavior, or how homebrew results are handled. The schema covers parameters but not broader tool 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 two sentences with no filler. It front-loads the core purpose and then adds the important usage distinction with omnisearch, making it easy for an agent to scan and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple search tool: it covers purpose, routing, and the return type. The rich schema covers all parameters. The lack of an output schema is a minor gap, but for a list-returning search tool the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters with meaningful descriptions. The tool description adds no parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation: searching D&D 5e vehicles or vessels by name and returning matching entries. It is specific enough to distinguish from the many sibling search tools that target other content types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('when you know the content type') and provides a direct alternative ('if unsure of the type, use omnisearch instead'). This gives an agent actionable routing guidance.
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 transparency burden. It clearly conveys a read-only search that returns a list of matching entries, but it does not disclose aggregate behaviors such as partial matching, default ruleset filtering, or how homebrew content is treated beyond what the schema parameters imply.
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 three short sentences with no filler. Purpose, result type, and routing guidance are all front-loaded and each sentence earns its place.
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 search tool, the description plus fully documented schema parameters are sufficient for correct invocation. The return shape is stated as a list of matching entries, and the omnisearch routing rule addresses the main ambiguity among sibling tools.
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 only reinforces the 'by name' query semantics without adding new meaning beyond the schema's parameter descriptions.
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 action ('Search'), a precise resource ('D&D 5e character backgrounds'), and the matching criterion ('by name'). It also distinguishes itself from the broad omnisearch sibling by explicitly referencing content-type awareness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence gives an explicit decision rule: use this tool when the content type is known and use omnisearch instead when unsure. This directly helps an agent choose between background_search and the fallback sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool returns 'the complete entry with description merged in,' which is meaningful information about the response structure. It does not cover failure behavior on no match, but for a lookup tool this is a reasonable level of 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?
Two short sentences with no wasted words. The central behavior is front-loaded, followed by the return characteristics and usage guidance. Every sentence earns its place.
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 lookup tool with full schema coverage, the description is nearly complete. It states the return payload ('complete entry with description merged in') and provides routing guidance. It does not describe not-found behavior, but the absence is minor because the tool is straightforward and the schema handles parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters at 100% coverage, so the baseline is 3. The description adds the phrase 'exact name,' which reinforces the required parameter's meaning, but it does not add meaning to source or ruleset beyond what the schema already states.
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 and resource: 'Get a specific D&D 5e published adventure by exact name.' It clearly distinguishes itself from sibling adventure_search by explicitly saying it should be preferred when an exact name is known, leaving no ambiguity about its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit routing guidance: 'Prefer this over adventure_search when you have an exact name.' This tells the agent when to use this tool versus a clear alternative. It also implies that adventure_search is the fallback when an exact name is not available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately characterizes the tool as informational — it 'returns aguide' and explains routing decisions, with no implied mutation or side effects. The only gap is that, absent an output schema, the exact form of the returned guide is left unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste: the core purpose is in the opening clause, and the second sentence adds routing value by naming the specific decision points. The enumeration of decision axes earns its place because it tells the agent exactly what guidance to expect.
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 tool with no annotations and no output schema, the description covers what the tool does, when to call it, and what decisions it resolves — sufficient for an agent to decide whether to invoke it. The only minor gap is the lack of detail on the output form, since no output schema exists to define it.
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 input schema is an empty object with zero parameters, so there are no parameter semantics to document. Per the baseline for 0-parameter tools, the description doesn't need to compensate for anything.
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 and resource: it 'returns a guide to all available 5eMCP tools and when to use each.' It clearly positions this as the meta-tool among 44 siblings, distinct from search, get, and DM-calculator tools because it explains their selection rather than performing their function.
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?
'Call this first when unsure which tool to reach for' is an explicit when-to-use condition, and the second sentence enumerates the decision axes it covers (omnisearch vs typed search vs _get tools, class feature lookups, book content, DM calculators, fetch_content fallback). It lacks an explicit when-not-to-use statement, though 'when unsure' implies the opposite condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full disclosure burden. It adds useful behavioral detail by stating that the complete entry is returned and that the description is merged in. It does not discuss failure behavior, but that is a minor gap for a simple exact-name lookup.
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 sentences, front-loads the core function, and avoids repetition of schema details. Every sentence earns its place, and the usage guidance is concise.
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 straightforward exact-name item lookup with a well-detailed input schema, the description covers the essential retrieval behavior and even mentions output merging. It is not missing any critical information needed to invoke the tool correctly, though it could briefly state what happens when no exact match exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the name parameter as an exact case-insensitive match, explains source as a disambiguation abbreviation, and defines the ruleset default. The description does not add meaningful semantics beyond what the schema already provides, so the baseline score 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?
The description clearly identifies the action (Get), the resource (a specific D&D 5e magic or mundane item), and the required input condition (exact name). It also differentiates this tool from item_search, helping an agent distinguish them without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to prefer this tool over item_search when an exact name is available. This gives direct selection guidance and names the alternative, leaving no ambiguity about when this tool should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It states that the tool returns 'the complete entry with description merged in,' which is useful observable behavior beyond what the schema reveals. It also communicates exact-name matching. It does not mention not-found/error behavior, but for a simple fetch operation this is a reasonably transparent description.
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 three sentences with no filler. The core purpose is front-loaded, the return behavior is stated, and the routing guidance to race_search is placed last. Every sentence earns its place.
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 getter with three parameters and no output schema, the description conveys the essential purpose, matching mode, and return behavior. It could mention error/not-found behavior, but the sibling list and schema already clarify the scope. The guidance distinguishing it from race_search completes the decision 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 documents all three parameters well. The description adds context by emphasizing exact-name lookup and the merged description, but it does not need to repeat parameter details. The baseline of 3 applies because the description adds only modest meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Get'), a specific resource ('a specific D&D 5e playable species or race'), and a clear selection criterion ('by exact name'). It also distinguishes itself from race_search by noting that exact names are the use case, which helps an agent choose between the two tools without opening 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to prefer this tool: 'Prefer this over race_search when you have an exact name.' This directly guides tool selection and names the alternative, giving clear decision criteria rather than leaving the choice implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It states that the tool returns a list of matching entries, which establishes the read-only search behavior, and clarifies the scope to playable species or races. It could add a bit more about result shape, but the core behavior is well communicated.
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 only two sentences and wastes no words. The core action and scope are front-loaded, and the alternative-tool guidance is placed immediately after. Every sentence provides signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool searches, what it returns, and when to prefer omnisearch instead. Since there is no output schema, it could optionally mention that full detail is available via race_get, but the provided guidance is sufficient for an agent to decide to call this search tool correctly.
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 every parameter is already documented in the schema. The description adds only a modest semantic detail by saying searches are 'by name', which aligns with the query parameter. This matches the baseline for full schema 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 states a specific verb ('Search'), a clear resource ('D&D 5e playable species or races'), and the matching mechanism ('by name'). 'Returns a list of matching entries' also sets it apart from a detail-fetch tool like race_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells an agent to use this tool when the content type is known, and directs uncertain cases to omnisearch. This clearly differentiates it from the sibling search tools and gives actionable routing guidance.
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?
No annotations are provided, so the description carries the burden. It communicates a read-only operation through 'Get' and adds a useful output detail: 'Returns the complete entry with description merged in.' It does not discuss error/not-found behavior, but for a simple read tool this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: what it gets, what it returns, and when to choose it over the sibling. No filler or repetition of schema content.
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 low-complexity getter with three params and no output schema, the description covers purpose, selection criterion, and return composition. It could be slightly more complete about what happens when no spell matches, but that is not a blocking gap.
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 reemphasizes 'exactly name,' mirroring the schema's name parameter, but adds no new meaning for the source or ruleset parameters.
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?
States a specific verb and resource: 'Get a specific D&D 5e spell by exact name.' It also distinguishes itself from spell_search by emphasizing the exact-name requirement, so an agent can tell them apart without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Prefer this over spell_search when you have an exact name.' This names the sibling alternative and gives the condition that selects this tool; the opposite case (use spell_search for non-exact/fuzzy queries) is clearly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does disclose the key behavior: the tool returns a list of matching entries rather than a single object. It does not cover edge behaviors such as empty results, pagination, or matching semantics, but the search-only nature and list output are sufficiently transparent for typical use.
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 sentences with no filler. The first sentence states the action and output, and the second sentence provides routing guidance, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a complete schema and no output schema, the description covers the important selection and invocation context: what is searched, what is returned, and when to use omnisearch instead. It could be slightly richer about result entry shape or default behavior, but the schema already covers the main invocation details.
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 applies and the schema already documents all seven parameters. The description adds no parameter-level detail beyond indicating that the query searches by name, but no information is lost because the schema 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 opens with a specific verb and resource: "Search D&D 5e spells by name." It also states the output form, "Returns a list of matching entries," and distinguishes itself from omnisearch by noting the condition for using the broader tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use this tool: when the content type is known. It also names an alternative, omnisearch, and gives the exact condition for switching to it, which is clear routing guidance among many sibling search tools.
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?
There are no annotations, so the description carries the behavioral burden. 'Get' implies a read operation, and 'Returns the complete entry with description merged in' discloses a useful output behavior beyond the schema. It does not address not-found or error behavior, but for a simple lookup that is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The main operation and return behavior are front-loaded, and the usage guidance is separated cleanly into the second sentence.
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 low-complexity get tool, the description adequately covers purpose, return behavior, and when to choose it over the search sibling. Parameter semantics are fully covered by the schema, and no output schema is needed given the explicit 'complete entry' statement.
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?
All three parameters already have descriptions in the schema, giving 100% schema description coverage. The tool description only repeats the 'exact name' concept and does not add meaningful parameter-level detail beyond what the schema already provides.
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 the verb 'Get', the resource 'a specific D&D 5e character background', and the selection criterion 'by exact name.' It also explicitly distinguishes itself from the sibling 'background_search', making tool selection unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit routing rule: 'Prefer this over background_search when you have an exact name.' This names the alternative and gives the condition that selects this tool, which is strong usage guidance.
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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly frames the tool as a read operation ('Get') and reveals what the caller receives ('complete entry with description merged in'), which is sufficient for a simple lookup. It does not describe error behavior for missing exact matches, but that is a minor gap for this tool type.
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 waste: the core action and exact-name condition come first, the return value second, and the routing guidance last. Every sentence earns its place.
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 lookup tool with only one required parameter and no output schema, the description provides the key invocation detail ('exact name') and the return expectation ('complete entry with description merged in'). Source and ruleset disambiguation are already covered by the schema, so nothing essential 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?
Schema description coverage is 100%, so the schema already fully documentents all three parameters. The description's phrase 'exact name' reinforces the name parameter but adds no new meaning beyond what the schema provides, so it earns the baseline score.
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 identifies the verb ('Get'), the resource ('specific D&D 5e feat'), and the distinguishing condition ('exact name'). It also names the sibling tool it should be preferred over (feat_search), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: when you have an exact feat name. It also names the alternative (feat_search) and says to prefer this tool in that case, implying search is for cases without an exact name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses the return format ('tag-resolved, metadata-stripped JSON'), the fallback behavior, and the file-listing behavior. It does not cover error cases or size/rate concerns, but for a read-only fetch tool the disclosure is solid.
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?
Four sentences with no wasted words. The fallback purpose is front-loaded, usage guidance follows, and the return format closes the description efficiently.
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 fallback file-fetch tool with no output schema, this description is complete: it explains when to use it, how to use it, what to omit to list files, and what kind of JSON to expect. An agent has enough context to invoke it correctly.
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 parameters in detail. The description reinforces the file_name omission behavior, but that is also present in the schema. It adds little beyond the baseline.
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 and resource: 'fetch any file in the manifest by content type and file name.' It also explicitly frames the tool as a fallback and distinguishes it from the typed _search and _get siblings, so an agent can tell them apart immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: prefer typed tools when available, use fetch_content for content types without a typed tool or for raw file access, and omit file_name to list files. This is strong when-to-use and when-not-to-use guidance.
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?
No annotations are provided, so the description carries the behavioral disclosure burden. It states that the tool searches by name and returns a list of matching entries, which covers the core behavior and output shape. It does not detail edge behaviors like result ordering, but for a simple search tool the transparency is adequate.
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 front-loaded, information-dense sentences with no redundant filler. Every clause adds value: what the tool finds, what it returns, when to use it, and what to use instead.
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 straightforward search tool with a fully described schema, the description covers purpose, usage guidance, the alternative tool, and the return type. No output schema is needed, and the simple nature of the operation means nothing critical 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?
Schema description coverage is 100%, so the schema already documents all five parameters. The description adds minimal parameter-level meaning beyond 'by name', which is already reflected in the query parameter description. A baseline of 3 is appropriate because the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Search D&D 5e skills by name') and clearly states the return type ('a list of matching entries'). It also differentiates itself from omnisearch, making the tool's scope unambiguous relative to a key sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit condition for use ('when you know the content type') and names the alternative ('use omnisearch instead') for uncertain cases. This is strong routing guidance that helps an agent choose correctly without additional inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It transparently states that the tool returns 'the complete entry with description merged in,' clarifying the output behavior. It does not mention failure modes or disambiguation caveats, but for a simple read-only retrieval this is reasonable coverage.
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 filler: the first states the operation and output, the second gives routing guidance. Every sentence earns its place and the key information 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?
For a simple exact-name retrieval tool, the description is complete: it defines the input condition (exact name), the return behavior (complete entry with merged description), and the alternative when the condition is not met (subclass_search). The schema covers the remaining parameter details.
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 coverage is 100% and every parameter already has a descriptive meaning, so the baseline is 3. The description does not add further semantic detail about parameters like source or ruleset beyond what the schema already provides.
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 and resource: 'Get a specific D&D 5e subclass or archetype by exact name.' It also distinguishes itself from the sibling subclass_search by explicitly noting the exact-name requirement, so an agent can clearly tell the two apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit routing guidance: 'Prefer this over subclass_search when you have an exact name.' This directly tells the agent when to use this tool versus its main alternative, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the behavioral burden and does so well by stating that resolvedFeatures contains complete feature text rather than reference strings. It also clarifies the edition-selection behavior of the ruleset parameter. It stops short of describing not-found behavior or the full shape of the class entry, but this is strong for a getter.
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 four short sentences, each earning its place: core action, returned data behavior, ruleset semantics, and alternative-tool routing. The most important behavioral detail about resolvedFeatures is front-loaded, and there is no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key invocation decisions: exact-name lookup, ruleset override, and which sibling tools to use for related feature or subclass needs. Since there is no output schema, a little more detail about the overall class entry structure would strengthen it, but the provided level of detail is sufficient for an agent to select and call this tool 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 schema already documents all three parameters and has 100% coverage, so the baseline is 3. The description adds substantive value by explaining that ruleset '2024' returns the XPHB version and '2014' returns the classic PHB version, giving the enum real meaning. It adds less for name and source, but the ruleset clarification is meaningful.
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 names a specific action, 'Get', and resource, 'D&D 5e character class', scoped to exact-name lookup. It also distinguishes itself from sibling search tools by explaining that results include a resolvedFeatures array with full feature text rather than references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes to alternatives for related needs: classfeature_search for features at a specific level and subclass_get or subclassfeature_search for subclass details. The exact-name scoping also implies that class_search is the better choice when the name is uncertain.
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:

[![5eMCP MCP server](https://glama.ai/mcp/servers/jazzsequence/5eMCP/badges/card.svg)](https://glama.ai/mcp/servers/jazzsequence/5eMCP)

Score Badge

Copy to your README.md:

[![5eMCP MCP server](https://glama.ai/mcp/servers/jazzsequence/5eMCP/badges/score.svg)](https://glama.ai/mcp/servers/jazzsequence/5eMCP)

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/jazzsequence/5eMCP'

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