devdocs-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: listing, metadata, semantic search, content retrieval, download, index rebuild, removal, and adding local/web sources. There is no ambiguity or overlap between any two tools.
Naming Consistency4/5
Most tools follow a verb_noun pattern (list_docs, search_docs, get_document, download_doc, remove_doc, rebuild_index), but 'doc_info' (noun_noun) and the add_local_source/add_web_source pair (verb_adj_noun) deviate slightly. Overall, the naming is still predictable and readable.
Tool Count5/5
Nine tools is well-scoped for a documentation management server. Each tool earns its place, covering source management, search, retrieval, and maintenance without redundancy.
Completeness5/5
The tool set covers the full lifecycle: adding local/web sources, downloading docs, listing/inspecting, searching, retrieving content, removing, and rebuilding the index. There are no obvious gaps or dead ends.
Average 4.2/5 across 9 of 9 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get detailed information' without stating that this is a read-only operation, what the output looks like, or any side effects. Minimal behavioral context is added beyond the name.
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, front-loaded with the main action. Every word earns its place, and the parameter example is efficient. It avoids fluff and is easy to parse.
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 is simple, but the description does not address how it differs from 'get_document' or what 'detailed information' includes. The output schema covers return values, but the description is incomplete for tool selection given the sibling ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description gives an example for the 'slug' parameter ('e.g. javascript, async'), adding semantic meaning that the schema does not provide. However, it does not explain the parameter's format, constraints, or how to find valid slugs, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('detailed information about a specific documentation'), making the purpose understandable. However, it does not distinguish itself from the sibling tool 'get_document', which likely serves a similar role, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of context, exclusions, or relationship to sibling tools, leaving the agent without decision criteria.
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 transparency burden. It discloses the side effect that files 'will be indexed for search,' which is useful. However, it does not mention permissions, idempotency, whether an existing source with the same slug is overwritten, or error behavior for invalid paths, leaving notable 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 concise and well-structured: a one-sentence purpose, a clarifying note about HTML files, then a clear two-line Args list. Every sentence adds value, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two required parameters and an output schema (though not shown). The description covers the main action and side effect, but omits details like return value, error conditions, and idempotency. Given the lack of annotations and the presence of an output schema, a bit more behavioral context would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining both parameters: 'path: Absolute filesystem path to the docs directory' and 'slug: Unique identifier for this local source.' This adds significant meaning beyond the schema's bare property names, though it stops short of specifying format constraints or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Add a local directory as a documentation source.' It distinguishes from the sibling tool add_web_source by specifying 'local directory' and is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by noting the directory should contain HTML files and that indexing will occur, but it does not explicitly state when to choose this tool over alternatives or provide caveats (e.g., prerequisites, when not to use). Sibling tool names suggest differentiation, but the description itself lacks explicit 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, the description carries the transparency burden. It discloses version-handling behavior ('ignored for multiple slugs, uses latest') but does not mention side effects like filesystem writes, network requirements, or authentication needs.
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 compact and well-structured, with a one-line summary followed by a clear Args block. Every sentence adds value; there is no redundancy or 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 is simple and has an output schema, so return values need not be described. However, there are gaps: no mention of when to prefer this over siblings, and no disclosure of potential side effects or prerequisites beyond the parameter details. It is minimally viable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates. It explains that slugs accepts a single string or list of strings with concrete examples, and clarifies that version is optional and ignored for multiple slugs—details not present in the bare 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 'Download one or more documentation bundles from devdocs.io,' using a specific verb and resource. It distinguishes from siblings like get_document (which likely fetches a single document) by emphasizing bundle downloads and supporting multiple slugs.
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 download documentation bundles but does not explicitly compare to alternatives such as get_document or list_docs. There is no 'when to use' vs '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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'Remove' which implies destructive action, but does not disclose whether the operation is permanent, reversible, or what happens to underlying files vs index entries. The mention of source types adds scope context, but key behavioral traits (side effects, reversibility) are missing.
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: a one-sentence purpose, a one-sentence scope clarification, and a brief args section. Every sentence earns its place, and the key detail (slug) 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 a single parameter, an output schema exists, and the tool is relatively simple, the description covers the essential aspects: what it does, what it works on, and what the slug parameter means. It lacks notes on side effects or prerequisites, but for a one-arg removal tool this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for the 'slug' parameter, and schema coverage is 0%. The description fully compensates by defining slug as 'Documentation slug to remove' and giving an example ('async'), which gives the agent clear semantic meaning.
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 begins with a clear, specific verb+resource: "Remove documentation by slug". It immediately distinguishes the tool from siblings like list_docs, search_docs, and download_doc by stating its core function and the argument (slug).
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 states "regardless of source type" and lists the supported source types (downloaded devdocs.io bundles, local sources, web sources), making it clear this is the universal removal tool. It does not explicitly name alternatives or exclusions, but the scope is well-defined.
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 mentions the doc_id format and source, but does not explicitly state that the operation is read-only, nor disclose error behavior, permissions, or side effects. The name 'get' implies safety, but the description lacks explicit behavioral disclosure, though this is a minor issue for such a simple retrieval 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?
The description is concise and well-structured: a clear purpose sentence, a usage sentence, and an args block with an example. Every sentence earns its place with no unnecessary repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get tool with an output schema, the description gives all necessary context for selection and invocation: how to get the ID, when to use it, and what it returns. It could mention error handling or limitations, but such details are not critical given the tool's simplicity and the presence of an output schema.
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 has no descriptions for the single parameter doc_id (0% coverage). The description compensates by explaining that it is the 'Document ID from search results' and gives a concrete example, providing the agent with sufficient understanding of what to pass.
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 'Get full document content by document ID' with a specific verb and resource. It further distinguishes from siblings by tying usage to search results ('after finding it via search_docs') and clarifying that the doc_id originates from search results, which differentiates it from tools like download_doc.
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?
Explicitly says 'Use this to retrieve the complete content of a document after finding it via search_docs,' giving a clear when-to-use context. It does not list when-not-to-use or alternatives, but the context is unambiguous enough for an agent to select it appropriately.
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?
The description discloses important behavioral nuance, such as min_score applying only to the vector search leg and that keyword/BM25 matches may surface regardless, which provides context beyond 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?
The description is well-structured with a clear first sentence followed by a compact Args section; each item is informative and necessary.
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?
With five parameters and no annotations, the description thoroughly explains all inputs, includes examples, and notes edge-case behavior, making it sufficient given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description compensates by explaining each parameter's purpose, defaults, and allowed values (e.g., source_type 'devdocs' or 'local'), including caveats for min_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 first sentence, 'Search documentation using semantic similarity,' clearly identifies the verb (search), resource (documentation), and method (semantic similarity), distinguishing it from sibling tools like list_docs or get_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for natural language queries but does not explicitly state when to prefer this over sibling tools like get_document or list_docs, nor does it provide exclusions or alternatives.
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 behavioral disclosure. It clearly states that by default only missing documents are indexed, clean=True rebuilds everything from scratch, and slugs ignores already-indexed status and re-indexes specified docs. This gives a solid understanding of side effects, though it could further mention impact on existing index data or concurrency.
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 well-structured and appropriately sized. It front-loads the core purpose, then uses a separate paragraph for default behavior and a bullet-like Args list for detailed parameter semantics. Every sentence adds value without unnecessary fluff.
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 tool's moderate complexity and the presence of an output schema, the description is quite complete. It covers all operation modes, parameter effects, and the relationship to 'downloaded documentation.' It could be slightly more explicit about prerequisites (e.g., docs must be downloaded first) and interaction with removal tools, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names, types, and defaults with 0% coverage, but the description's Args section fully explains each parameter's meaning and effect. For example, it clarifies that clean=True rebuilds entirely from scratch and that slugs accepts a list like ['vulkan', 'python'] to re-index specific docs, going well 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 opens with a clear, specific action: 'Rebuild the embedding index from downloaded documentation.' This distinctly identifies the tool's function and differentiates it from siblings like list_docs, search_docs, and download_doc, which do not perform index rebuilding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool by explaining the default incremental behavior, the clean=True full rebuild, and the slugs parameter for targeted re-indexing. It does not explicitly mention alternatives or exclusions, but the usage modes are well specified.
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 exist, so the description carries the burden. It discloses significant behavior: directory restriction, HTML-only crawling, non-HTML skipping, and default behavior. However, it does not mention auth requirements, rate limits, or whether re-downloading overwrites existing data—minor but notable 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 well-structured with a short intro, behavioral details with an example, and a labeled Args list. Every sentence contributes useful information, balancing detail with readability.
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 tool with 6 parameters, no annotations, and an output schema, the description is sufficiently complete. It covers param semantics, defaults, crawling behavior, and edge cases like no url provided. The output schema covers return values, so no description of return format is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by explaining every parameter (slug, url, name, max_depth, pattern, url_prefix) with clear semantics and defaults. It adds meaning beyond the raw schema, such as the pattern's regex meaning and url_prefix's directory default.
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 primary action: 'Fetch documentation from a web URL', and also the secondary mode: 're-download existing source'. It distinguishes from siblings through 'web URL' vs local source, making the tool's scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: fetch from a web URL or re-download by slug. It provides a clear conditional for re-download but does not explicitly compare with alternatives like add_local_source. No exclusions are stated, but the 'web' vs local distinction is 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, the description carries the full burden. It discloses defaults (include_large=False, downloaded_only=True), the 50MB threshold, and query semantics (metadata only, case-insensitive substring). It does not explicitly state read-only behavior, but that is inherent in 'list' and not misleading.
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 opening sentence is a crisp summary, and the Args list is scannable and well-structured. Each parameter line adds distinct value without redundancy, making the description both concise and complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 optional parameters and an output schema for return structure, the description fully covers invocation semantics. It also warns that query does not search content, preventing a common misuse. This is complete for an agent to select and use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description fully compensates by explaining each parameter: source_type values ('devdocs', 'local', None), include_large threshold and default, downloaded_only default, and query's matching behavior and scope. This is essential and effectively communicated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available documentation sources with optional filtering. The verb 'list' and resource 'documentation sources' are specific, and it differentiates from siblings like search_docs (content search) and get_document (retrieval).
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?
Provides clear context for when to use the tool (to see documentation sources) and includes an exclusion: the query parameter 'does NOT search document content,' implying that for content search you would use a different tool. However, it does not explicitly name alternative tools or provide when-not-to-use scenarios.
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:

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

Score Badge

Copy to your README.md:

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

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/HellButcher/devdocs-mcp'

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