Provides tools to list official EverQuest Legends YouTube videos from the channel RSS feed and fetch transcripts from YouTube videos using published captions.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@EverQuest Legends MCP search the EQL wiki for 'Faydwer armor'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Read-only Model Context Protocol server for EverQuest Legends public sources.
Stable (1.0). Read-only. It does not require secrets, cookies, credentials, a Daybreak account, or private API access. The only optional moving part is the yt-dlp helper used by eql_video_transcript (see Optional Dependencies).
Related MCP server: reddit-mcp
This MCP is for EverQuest Legends. It intentionally excludes general EQ1/EQ2, P99, EQEmu, Project Quarm, and other emulator/background databases unless a specific page is about EverQuest Legends.
This server is built around public, unauthenticated sources:
EQL Wiki: https://sergeantfirstclassvincetoxicumnegrum35.github.io via MediaWiki API
Official EQL site and news: https://sergeantfirstclassvincetoxicumnegrum35.github.io
Daybreak help and press pages
Official EverQuest community note about the Game Jawn collaboration
Official EQL YouTube and Twitch channels
EQL-specific guide/interview/preview pages from EQProgression, EverQuest Guides, and selected press outlets
Pointer-only EQL community sources such as Reddit
It does not log into Daybreak, manipulate an account, automate a game client, or send requests to private APIs.
eql_sources: list configured public sources
eql_source_fetch: fetch and extract a curated source page
eql_source_search: search official/support/guide source pages
eql_wiki_search: full-text search EQL Wiki
eql_wiki_page: fetch an EQL Wiki page with extracted text, links, categories, and revision metadata
eql_wiki_recent_changes: read recent wiki edits
eql_wiki_category_pages: list MediaWiki category members
eql_official_news: parse official EQL news index
eql_official_article: fetch and extract an official news article
eql_press_assets: list official Daybreak press asset URLs by kind
eql_official_youtube_videos: list official EQL YouTube video metadata from the channel RSS feed
eql_video_transcript: fetch an existing transcript from a YouTube video's published captions (uses yt-dlp, auto-downloaded on first use; see Optional Dependencies)
eql_class_combos: generate three-class combinations from the public 16-class list
eql://sources: source registry
eql://classes: class metadata
eql://races: launch race list
eql_video_transcript uses yt-dlp to read a video's published captions. Every other tool works without it, and nothing is downloaded unless you actually call this tool.
yt-dlp is required because YouTube now gates caption downloads behind a bot-check token that plain HTTP requests cannot satisfy. No video or audio is downloaded — captions only.
How yt-dlp is resolved, in order:
YTDLP_PATH environment variable, if set.
A yt-dlp already on your PATH (e.g. brew install yt-dlp / pipx install yt-dlp). A system copy you keep updated is preferred and always wins.
A copy previously downloaded by this server (see below).
If none of those is present, the tool does not download anything silently. The first call returns a short message explaining that yt-dlp is needed to pull YouTube captions and asking you to opt in. To proceed, call eql_video_transcript again with installYtDlp: true. That authorizes a one-time download of the official standalone yt-dlp binary from GitHub releases, verified against the release's published SHA-256 checksum, then cached. The macOS/Linux standalone builds are self-contained (no Python required).
Download details:
Cache location: ~/Library/Caches/everquest-legends-mcp (macOS), $XDG_CACHE_HOME/everquest-legends-mcp or ~/.cache/everquest-legends-mcp (Linux), %LOCALAPPDATA%\everquest-legends-mcp (Windows).
The cached binary is refreshed (best-effort) after 7 days to keep up with YouTube changes.
Set EQL_YTDLP_AUTODOWNLOAD=1 to grant standing consent so the download happens automatically without the per-call installYtDlp flag.
Twitch is intentionally unsupported: Twitch VODs do not expose retrievable captions, so the tool returns a clear "not available" result for Twitch URLs.
Prerequisites:
Node.js >=22
npm
This is a stdio MCP server. Your MCP client starts it as a child process.
It is distributed via GitHub (not the npm registry). MCP clients that accept a JSON config can run it directly from the repository with npx, which clones, builds, and launches it:
{
"mcpServers": {
"everquest-legends": {
"command": "npx",
"args": ["-y", "github:ArtSabintsev/everquest-legends-mcp"]
}
}
}Pin to a release tag for reproducibility, e.g. github:ArtSabintsev/everquest-legends-mcp#v1.1.0. For a fixed local install, see Local Development below and point your client at dist/index.js.
git clone https://sergeantfirstclassvincetoxicumnegrum35.github.io
cd everquest-legends-mcp
npm install
npm run buildFor MCP clients that accept a JSON config:
{
"mcpServers": {
"everquest-legends": {
"command": "node",
"args": ["<path-to-checkout>/dist/index.js"]
}
}
}npm run typecheck
npm test
npm run buildTool | Required input | Typical use |
| none | List every configured source and see whether each source is searchable or pointer-only. |
|
| Fetch extracted text for a searchable source from |
|
| Search curated official, guide, and press sources for EQL-specific text; failed fetches are returned in |
|
| Search the EQL Wiki through MediaWiki full-text search. |
|
| Read an EQL Wiki page after finding it with |
|
| List pages in an EQL Wiki category. |
| none | List official EverQuest Legends news articles. |
|
| Read an official EQL news article by slug or |
|
| List official Daybreak press asset metadata for |
| none | List official EverQuest Legends YouTube video metadata from the channel RSS feed. |
| none | Generate EQL three-class combinations from the public 16-class list. |
Example user prompts for an MCP client:
"Use eql_sources, then fetch the official shop source."
"Search the EQL Wiki for race unlocks, then read the most relevant page."
"List official press screenshots for EverQuest Legends."
"Show the latest official EverQuest Legends YouTube videos."
Searchable sources should be stable public text pages about EverQuest Legends.
Official EQL, Daybreak, Game Jawn, original interviews, hands-on previews, and EQL-specific guide pages are preferred.
Social, Discord, forum, Twitch, and YouTube watch pages are pointer-only unless there is a stable public feed or transcript.
Daybreak Help pages are pointer-only because direct fetches can return Cloudflare challenge HTML.
Binary assets are exposed as metadata links; they are not downloaded by default.
The wiki and beta coverage change quickly. For current facts, prefer eql_wiki_page, eql_wiki_search, eql_official_news, eql_official_youtube_videos, and official source pages over static assumptions.
EQL launches pre-Kunark (Antonica, Faydwer, Odus, plus the classic Planes of Sky, Hate, and Fear). The community wiki inherits classic EverQuest data, so pages routinely describe Kunark, Velious, and Luclin zones, cities, factions, items, and quests that are not in the launch game. eql_wiki_page, eql_wiki_search, and eql_source_fetch attach a structured eraAdvisory when they detect such references — check for it and do not treat flagged content as launch-live.
MIT
Generate three-class EQL combinations from the 16 public wiki classes. This is a planning helper, not a race/primary-class validator.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| exclude | No | Classes or abbreviations to exclude. | |
| include | No | Classes or abbreviations that must be present, for example WAR or Cleric. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states what it generates but does not discuss side effects, safety, or any non-obvious behavior. It is minimally transparent; a 3 is appropriate as it gives a basic understanding without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no unnecessary words, and front-loads the purpose. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the complexity of generating combinations, the description is too brief. It does not explain the output format, how combinations are generated (e.g., order, uniqueness), or the role of parameters. This leaves an agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (exclude and include have descriptions, limit does not). The description adds no parameter information, failing to explain how limit, exclude, or include affect the output. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates three-class EQL combinations from 16 public wiki classes, using a specific verb and resource. It also distinguishes itself from a validator, which helps clarify its role among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that it is a planning helper, not a validator, implying when to use it. However, it does not explicitly mention alternatives or when not to use it, but given sibling tools are mostly for fetching content, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch an official EverQuest Legends news article by page name or official /news/ URL.
| Name | Required | Description | Default |
|---|---|---|---|
| maxCharacters | No | ||
| pageNameOrUrl | Yes | Article page name such as everquest-legends-preorder, /news/..., or https://www.everquestlegends.com/news/... URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the fetch action and does not disclose that maxCharacters may truncate responses, any error handling, or safety profile (e.g., read-only). Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clear sentence, front-loaded with the action, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal annotations, the description lacks details on return format, maxCharacters behavior, error cases, or what happens when the article doesn't exist. Incomplete for a fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds little beyond the schema for pageNameOrUrl, and does not mention maxCharacters at all, failing to compensate for the 50% schema description coverage. The schema already explains pageNameOrUrl well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches an official EverQuest Legends news article, specifies the resource and how to identify it (by page name or /news/ URL), and distinguishes from sibling tools that list news or videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have a specific article page name or URL, but does not explicitly state when to use this vs alternatives like eql_official_news for listing, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse the official EverQuest Legends news index.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility for behavioral disclosure. It only says 'Parse the official EverQuest Legends news index', which implies a read operation, but does not confirm idempotency, potential side effects, authentication needs, or rate limiting. The term 'Parse' could be misinterpreted as a destructive or processing action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it sacrifices informativeness for brevity; a slightly longer description could add value without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter, no output schema, and no annotations, the description is insufficient. It does not describe the return format, pagination behavior, or how this tool relates to siblings like 'eql_official_article' (which likely fetches a specific article). An agent needs more context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation coverage is 0%, meaning the description adds nothing about the single parameter 'limit'. The schema provides numeric bounds and a default, but the description does not explain how the limit affects results (e.g., number of news items returned) or any formatting constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Parse' is ambiguous; it suggests processing rather than listing. The description states the tool operates on the 'official EverQuest Legends news index', but does not clarify what it returns (e.g., list of news items, summaries, metadata). It distinguishes from sibling 'eql_official_article' (which likely retrieves a single article) only by the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'eql_official_article' or 'eql_source_fetch'. There is no mention of prerequisites, typical use cases, or conditions that would make another tool more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the official EverQuest Legends YouTube RSS feed and return video metadata. This does not download video or transcripts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description explicitly states it is a read-only operation that does not download videos or transcripts. This directly addresses behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose and a key limitation. No wasted words; front-loaded with primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately states the tool's function but omits information about the limit parameter and does not describe the returned metadata structure. For a simple tool with one parameter, it is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'limit' is not mentioned in the description despite 0% schema description coverage. The schema itself is clear, but the description fails to add meaning or usage guidance for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'official EverQuest Legends YouTube RSS feed', specifying it returns video metadata. It distinguishes from sibling tools like eql_video_transcript by excluding downloads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing videos and not for obtaining transcripts or downloads. While it doesn't explicitly compare with siblings, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List official Daybreak press asset URLs for EQL. This returns metadata and links only; it does not download binary assets.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Press asset kind to list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns only metadata and links, not binary assets, which adds behavioral context beyond what annotations (none provided) would convey. This helps the agent understand the tool's scope of work.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no redundant information. The first sentence states the primary action, and the second sentence clarifies constraints, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description adequately covers the return type (metadata and links) and what it excludes (downloads). No further details are necessary for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with a single parameter 'kind' described via an enum. The tool description does not add any additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (list), resource (press assets), and scope (official Daybreak, for EQL). It distinguishes itself from sibling tools by specifying its focus on press assets, such as logos, artwork, screenshots, etc., which are not covered by other tools like eql_official_article or eql_wiki_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. The agent can infer usage from the purpose, but lacking explicit context reduces the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and extract text from a searchable curated public source by id. When the text references content from a later expansion (Kunark, Velious, Luclin) that is not in EQL's pre-Kunark launch, the result includes an eraAdvisory.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Source id from eql_sources, for example official-home or eqprogression-faq. | |
| maxCharacters | No | Maximum extracted text length. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It notes the eraAdvisory behavior, which is a valuable nuance. However, it omits any mention of error handling, rate limits, or that the tool is read-only, though these are partially implied by the fetch action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first sentence states the primary action, second adds a key behavioral detail. No filler or repetition, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with two well-described parameters and no output schema, the description adequately covers input and a notable output feature (eraAdvisory). It could be improved by briefly describing the full output structure (e.g., text plus advisory), but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters. The description adds no extra meaning beyond reinforcing that id identifies the source, but doesn't explain maxCharacters or provide additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Fetch and extract text from a searchable curated public source by id'), clearly distinguishing it from sibling tools like eql_sources (which lists sources) and eql_source_search (which searches). The unique eraAdvisory behavior further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like eql_source_search or eql_sources. It implies usage when a specific id is known, but provides no exclusions or context for choosing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List curated EverQuest Legends public sources known to this server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It says 'curated public sources known to this server,' implying a static list, but doesn't explain if it's cached or dynamic. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, immediately conveys the tool's action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is mostly complete. It doesn't detail output format, but that's acceptable given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds no param info. Baseline 4 is justified as schema coverage is 100% and no param details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists curated EverQuest Legends public sources. It uses a specific verb ('List') and resource ('sources'), distinguishing it from search or fetch tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings like eql_source_search or eql_source_fetch. The AI agent receives no help in choosing the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across curated official, support, and guide pages. Use wiki-specific tools for full wiki search.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Search terms. | |
| sourceIds | No | Optional source id filter from eql_sources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only says 'Search across curated... pages' with no mention of authentication, rate limits, result format, or side effects. This is insufficient for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The action is front-loaded ('Search across...'), and the guidance is direct. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and no annotations, the description is too brief. It does not clarify the scope of 'curated', how results are presented, or pagination behavior. A search tool needs more context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (descriptions for 'query' and 'sourceIds' but not 'limit'). The description does not add any extra meaning or usage context beyond the schema. It fails to explain important parameters like 'limit' or 'sourceIds', leaving the agent to rely solely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches across curated official, support, and guide pages. It also distinguishes from sibling tools by advising to use wiki-specific tools for full wiki search. The verb 'search' and resource 'curated sources' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for searching curated pages, and explicitly says to use wiki-specific tools for full wiki search. This gives a when-not-to-use hint. However, it does not detail alternatives among the many sibling tools or specify prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch an existing transcript for a video from its published captions. Supports YouTube video ids and URLs (watch, youtu.be, shorts, embed, live). Twitch is not supported because Twitch VODs do not expose retrievable captions. This reads existing captions only; it does not transcribe audio. Pulling YouTube captions requires the yt-dlp helper; if it is not installed, call again with installYtDlp set to true to download it.
| Name | Required | Description | Default |
|---|---|---|---|
| urlOrId | Yes | YouTube video id or URL, for example DsswWPXweW8 or https://www.youtube.com/watch?v=DsswWPXweW8. | |
| language | No | Preferred caption language code, for example en or en-US. | en |
| installYtDlp | No | Authorize a one-time download of the yt-dlp helper (~36 MB, checksum-verified) if it is not already installed. Required to pull YouTube captions when yt-dlp is absent. | |
| maxCharacters | No | Maximum transcript text length. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: reads existing captions, requires yt-dlp helper, and provides installation instructions. It could be improved by mentioning error scenarios or authorization, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the main purpose. Each sentence adds distinct value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no output schema, the description covers essential aspects: core function, parameter guidance, limitations, and prerequisites. It could mention the return format, but it is still sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value by enumerating accepted YouTube URL formats (watch, youtu.be, shorts, embed, live) and explaining the installYtDlp parameter in context. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it fetches a transcript from published captions, specifies supported YouTube URL formats, and clarifies it does not transcribe audio or support Twitch. This clearly distinguishes it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (fetch existing transcript) and when not (Twitch, no audio transcription). It also instructs on installing yt-dlp if needed. However, it does not explicitly compare to other eql tools for transcript retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pages in a MediaWiki category, for example Zones, NPCs, Equipment, or Bard Build.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| category | Yes | Category name with or without Category: prefix. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states purpose but omits behavioral details like idempotency, authentication needs, or pagination behavior. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with examples, no unnecessary words. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Acceptable for a simple listing tool, but lacks mention of pagination or output format. Could benefit from a brief note on the 'limit' parameter behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'category' described). Tool description adds no parameter information beyond what's in the schema; does not explain 'limit' or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists pages in a MediaWiki category with concrete examples (Zones, NPCs, etc.), distinguishing it from siblings like single page fetch or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus alternatives (e.g., eql_wiki_page for single page, eql_wiki_search for searching). Agent must infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a page from EQL Wiki via MediaWiki API and return extracted text, links, categories, and revision metadata. Pages inherit classic EverQuest data; when the text references later-expansion content (Kunark, Velious, Luclin) not in EQL's pre-Kunark launch, the page includes an eraAdvisory.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Wiki page title, for example Character Classes, Nagafen, or Build Guides. | |
| maxCharacters | No | Maximum extracted body length. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses core behavior (fetch, return components, era advisory) but omits error handling, authentication needs, or rate limits. Reasonably transparent for a read-only fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first covers core action and outputs, second adds a key behavioral note on eraAdvisory. No extraneous words, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate given simple tool with 2 params and no output schema. Covers basic functionality and a special case, but lacks details on return format (e.g., JSON structure), error scenarios (e.g., page not found), and how to interpret outputs like links and categories.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters fully. Description adds value by specifying the return structure (extracted text, links, categories, revision metadata) beyond the schema. This compensates for the schema's focus on input alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'fetch', resource 'page from EQL Wiki', and specific outputs (extracted text, links, categories, revision metadata). Includes unique detail about eraAdvisory, distinguishing it from sibling tools like search or category listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when needing a specific page's content, but lacks explicit guidance on when to use this tool versus alternatives like eql_wiki_search or eql_wiki_category_pages. No when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return recent public edits from the EverQuest Legends Wiki.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It only states 'recent public edits' without mentioning ordering, pagination, or other behavioral traits. The parameter limit is left to 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with no waste. However, it could be expanded slightly without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema), the description is too minimal. It omits return format, ordering, and the effect of the limit parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description does not explain the limit parameter at all. The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'recent public edits from the EverQuest Legends Wiki', using a specific verb and resource. It distinguishes well from siblings like eql_wiki_page (single page) and eql_wiki_search (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like eql_wiki_page or eql_wiki_search. The usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search the public EverQuest Legends MediaWiki. The wiki inherits classic EverQuest data; when result snippets reference later-expansion content (Kunark, Velious, Luclin) not in EQL's pre-Kunark launch, the response includes an eraAdvisory.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | MediaWiki search query. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description discloses that results include an eraAdvisory because the wiki inherits data from later expansions. However, it omits details about read-only nature, rate limits, authentication requirements, or handling of empty results. The behavioral disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. Each sentence adds distinct value: the first states core purpose, the second provides a key behavioral note. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers the search action and a specific output advisory, but does not describe the full response structure (e.g., result list, snippets, scores) or pagination. Adequate for a simple tool but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'query' has a description). The description does not add parameter-level information beyond the schema. 'limit' lacks description both in schema and description. The description adds global context (full-text, eraAdvisory) but not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Full-text search the public EverQuest Legends MediaWiki.' Clearly identifies the action (search) and resource (MediaWiki), differentiating it from sibling tools like eql_wiki_page (specific page retrieval) and eql_wiki_category_pages (category listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Does not explicitly state when to use this tool over alternatives. The description implies usage for full-text search, but lacks guidance on when not to use it or comparisons to siblings. The eraAdvisory note provides context but not decision logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.0eql_class_comboseql_official_articleeql_official_newseql_official_youtube_videoseql_press_assetseql_source_fetcheql_source_searcheql_sourceseql_video_transcripteql_wiki_category_pageseql_wiki_pageeql_wiki_recent_changeseql_wiki_searchScored across 13 tools
Each tool has a clearly distinct purpose: class combinations, official articles, news, YouTube videos, press assets, sources (list, search, fetch by ID), video transcripts, and wiki operations (category pages, page fetch, recent changes, search). No two tools overlap in functionality.
All tools start with the 'eql_' prefix and use underscore-separated descriptive names. While not strictly verb_noun (e.g., 'eql_class_combos', 'eql_press_assets'), the naming is consistent and predictable, making tool purposes clear.
With 13 tools, the server covers multiple domains (official news, wiki, sources, videos, press assets) without being overwhelming. Each tool serves a specific need, and the count is well-scoped for an information-retrieval MCP server.
The tool surface covers core information sources: official news, wiki full text and categories, curated sources, videos, and transcripts. Minor gaps exist (e.g., no tool for official forums or patch notes), but the main workflows for gathering information about EverQuest Legends are supported.
Read-only MCP for the Eco game wiki: search, Markdown pages, and wiki_* lookups. No keys, no writes.
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
MCP gateway for getbotlens.com: articles, search and full text. Read-only, no auth.
Public read-only MCP server for HODLXXI agent identity, trust, receipts, and verification.
