What can you do with this server?

This server reads HPE Support Center documents and exposes them to LLM agents as text. * Fetch full HPE documents by doc ID or URL, optionally reading all topics or a specific page. * List a document's table of contents / topics cheaply. * Search HPE knowledgebase by keyword (requires HPE_SESSION_COOKIE; otherwise returns authentication_required). * Report the latest known Morpheus release from a configured list of release-notes documents. * Caches and throttles upstream requests, returns errors as readable text, and explicitly truncates long documents.

Which integrations are available for this server?

Provides tools for reading HPE Support Center knowledgebase documents as text, listing document topics, searching the knowledgebase when an authenticated session is available, and checking the latest known HPE Morpheus release.

How do I use HPE Knowledgebase MCP server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@HPE Knowledgebase MCP server What changed in the latest Morpheus Enterprise release?" 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.

HPE Knowledgebase MCP server

by tgessendorfer

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

HPE Knowledgebase MCP server

tests

An MCP server that reads HPE Support Center documents and hands them to an LLM agent as text. Built for HPE Morpheus Enterprise Agents, but it is a plain MCP server and works with any client.

Independent community project. Not an official HPE product, and neither endorsed by nor affiliated with Hewlett Packard Enterprise.

Why this exists

An agent with a web search tool can find HPE documentation but cannot read it. support.hpe.com/hpesc/public/docDisplay?docId=... is a JavaScript viewer: fetch that URL and you get about 9 KB of navigation chrome and no document text. So an agent asked "what changed in the latest release" ends up reasoning from search-result snippets, and says it could not confirm anything.

Underneath the viewer is a plain, unauthenticated API that serves the same documents as HTML and JSON. This server talks to it.

Endpoint	Returns
`GET /hpesc/public/api/document/{docId}`	the whole document (`Content-Type: htmlzip`), or just front matter when it is split into topics (`multiPage`)
`GET /hpesc/public/api/document/{docId}/toc`	topic list, each with a render link
`GET /hpesc/public/api/document/{docId}/render?page=GUID-….html`	one topic, as JSON with a `page_html` field
`GET /hpesc/public/api/document/{docId}/search?q=…`	needs a signed-in HPE account

The asymmetry is the thing to understand: HPE serves documents anonymously but gates search behind a login. So discovery and retrieval are split — the agent's own web search finds the docId, this server reads the document.

Related MCP server: MCP RAG Server

Tools

Tool	What it does
`get_hpe_document(document, page=None, include_all_topics=False)`	Reads a document as text. Takes a bare `docId` or any URL containing one, so a pasted browser link works. Multi-page documents return their topic list first; pass a `page`, or `include_all_topics=true`.
`list_hpe_document_topics(document)`	Table of contents only — cheap when you want just "Fixes".
`search_hpe_kb(query)`	Keyword search. Requires `HPE_SESSION_COOKIE`; without it returns `authentication_required` and tells the model to use web search instead.
`get_latest_morpheus_release(product)`	Newest release this server knows about, with version, month and link.

About `get_latest_morpheus_release`

It compares a configured list of release-notes documents rather than querying HPE, because there is no anonymous search API to query. Seeded with the Morpheus Enterprise and VM Essentials release notes that exist today.

Point HPE_KB_DOCUMENTS at your own JSON file to extend it:

[
  {"product": "morpheus-enterprise", "doc_id": "dp00008463en_us"},
  {"product": "morpheus-enterprise", "doc_id": "sd00008269en_us"}
]

Document ids are not sequential and the prefix changes between releases (sd… then dp…), so a new release means a new entry — nothing here guesses a URL pattern. The tool says so in its own output, and the agent can always find a newer document with web search and read it with get_hpe_document.

Install and run

Run it from a checkout:

git clone https://github.com/tgessendorfer/hpe-kb-mcp
cd hpe-kb-mcp
python3 -m venv .venv
./.venv/bin/pip install -e .

# For Morpheus (network-reachable):
./.venv/bin/python -m hpe_kb_mcp.server --transport streamable-http --host 0.0.0.0 --port 8081
# For local testing with a stdio client:
./.venv/bin/python -m hpe_kb_mcp.server --transport stdio

There is no published package — this is not on PyPI and is not meant to be installed by name.

Flag / variable	Default	Notes
`--host` / `HPE_KB_HOST`	`0.0.0.0`
`--port` / `HPE_KB_PORT`	`8081`
`--path` / `HPE_KB_PATH`	`/mcp`	endpoint path
`--stateless`	off	try it if the Morpheus client fails to hold a session
`--allowed-host HOST`	off	turns on DNS-rebinding protection; repeatable. Off means any `Host` header is accepted — fine on a trusted network, worth setting otherwise
`HPE_SESSION_COOKIE`	unset	only needed for `search_hpe_kb` and entitlement-gated documents
`HPE_KB_CACHE_TTL`	`900`	seconds
`HPE_KB_MIN_INTERVAL`	`0.5`	seconds between upstream requests

Nothing here needs credentials for public product documentation. Set HPE_SESSION_COOKIE (the Cookie header value from a signed-in browser session) only if you need search or a gated document; sessions expire, so treat that as a convenience, not infrastructure.

As a service

# /etc/systemd/system/hpe-kb-mcp.service
[Unit]
Description=HPE knowledgebase MCP server
After=network-online.target

[Service]
User=hpe-kb
WorkingDirectory=/opt/hpe-kb-mcp
ExecStart=/opt/hpe-kb-mcp/.venv/bin/python -m hpe_kb_mcp.server \
  --transport streamable-http --host 0.0.0.0 --port 8081
Restart=on-failure
Environment=HPE_KB_CACHE_TTL=3600

[Install]
WantedBy=multi-user.target

Wiring it into HPE Morpheus

Tools > AI Services > MCP Servers → add this server's URL (http://<host>:8081/mcp).
Tools > AI Services > Agents → edit the agent and add it alongside Morpheus (Built-in).
Leave Read-only mode unchecked on the agent — see below.
Start a new conversation — an existing one keeps the tool catalog it opened with.

Read-only agents cannot call external tools. Verified against Morpheus 9.0.1: an agent with Read-only mode checked discovers and loads these tools happily, then fails every call with Write operations are disabled for this agent (read-only mode). Morpheus classifies every external MCP tool as a write. Declaring the tools read-only does not help — they all carry readOnlyHint, and 9.0.1 ignores it. The setting only ever guarded Morpheus's own write tools, so unchecking it exposes nothing about this server, whose four tools are GETs against support.hpe.com. To keep that guard, run two agents: a read-only one without this server, and a documentation one with it.

Do not verify a registration by asking the agent whether it has get_hpe_document — it will say no even when everything works. Morpheus does not put external tools in the model's prompt; it exposes them through search_external_tools and load_external_tools, and renames them external__<id>__<tool>. Ask it to run search_external_tools instead. Nothing reaches this server between registration and the first real call, so a quiet access log is expected.

Worth adding to the agent's system prompt, since it steers the split cleanly:

For questions about HPE product releases, documentation or known issues, use the HPE knowledgebase tools. Use the Morpheus tools for what is actually deployed on this appliance. Never state a release version from memory. When citing a document, print its full URL as plain text on its own line — not markdown link syntax, and not the bare document id.

That last line is a workaround for the chat UI, which renders neither markdown links nor bare URLs as anchors (Morpheus 9.0.1). Nothing here can produce a clickable link; a full URL is at least selectable in one go, where a bare dp00008463en_us leaves the reader to assemble it. Drop the line if a later release renders markdown — the tools already return a url field, so proper links come back for free.

The appliance must be able to reach this server. Runs happily next to the appliance or on it.

Behaviour worth knowing

Caching and throttling. Responses are cached (15 minutes by default) and upstream requests are serialised with a minimum interval, so an agent that fans out does not turn into a burst of traffic against HPE's portal.
Errors are returned, not raised. Tools answer with {"error": "...", "detail": "..."} so the model can read what went wrong and adjust, rather than seeing a transport failure.
Truncation is explicit. Long documents come back with truncated: true and a [truncated] marker instead of silently losing the tail.
This reads a vendor portal. It is polite by construction — cached, throttled, honestly identified in its User-Agent — and reads only documents HPE serves publicly. Keep it that way if you extend it.

Tests

./.venv/bin/python -m unittest discover -s tests -t .

Offline: the fixtures mimic the shape of HPE's payloads, not their content, so the suite needs no network and carries none of HPE's documentation. That is also why CI needs no secrets — GitHub Actions runs the same command on 3.10, 3.12 and 3.13 on every push and pull request.

tests/test_server.py covers what the appliance actually reads: that every tool is annotated read-only, that each carries a description, and that the server reports a version. A tool added without those would pass every other test and fail only once it reached Morpheus.

Versioning

__version__ in hpe_kb_mcp/__init__.py is the single source — pyproject.toml reads it, and the server reports it as serverInfo.version. Bump that one line and everything follows. Deployments track this repository directly; there is no build or publish step.

Available Tools

4 tools

get_hpe_documentA

Read the full text of an HPE Support Center document.

Use this for any support.hpe.com document - release notes, advisories, customer notices, product documentation. Fetching a support.hpe.com/hpesc/public/docDisplay?docId=... URL with a normal web fetch returns an empty JavaScript shell with no document text; this tool reads the API underneath it and returns the real content.

document accepts either a bare document id (dp00008463en_us) or any URL containing one, so a link pasted from a browser works as-is.

Large documents are split into topics. Called without page, this returns the topic list so you can pick one; call it again with that topic's page value to read it, or pass include_all_topics=true to read the whole document at once.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`document`	Yes
`max_chars`	No
`include_all_topics`	No

TDQS

A4.4/5.0

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 provides valuable context: a normal web fetch returns an empty JavaScript shell, so this tool reads the underlying API; large documents are split into topics; calling without page returns the topic list; include_all_topics reads the whole document. This gives meaningful behavior beyond the schema, though it does not cover error behavior, rate limits, or response formatting.

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 front-loaded with the core purpose, then efficiently explains the technical workaround, parameter flexibility, and pagination workflow. Every sentence adds value and there is no redundant or filler content. The structure is easy to parse and directly supports correct 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?

Despite lacking an output schema and annotations, the description covers the essential usage workflow: how to pass a document, how to navigate topics, and how to retrieve everything at once. It explains why the tool exists and what makes it different from a normal fetch. The main gaps are the unaddressed max_chars parameter and lack of explicit return format details, but the core invocation path is well covered.

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%, so the description must compensate. It thoroughly explains document (bare ID or URL containing one), page (use topic's page value), and include_all_topics (read whole document at once). However, max_chars is never mentioned, leaving its meaning and interaction with pagination unclear. For three of four parameters, semantics are excellent; the omission of max_chars prevents a 5.

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: 'Read the full text of an HPE Support Center document.' It clearly distinguishes itself from siblings: list_hpe_document_topics only lists topics, search_hpe_kb searches, and this tool retrieves full document text. The scope is explicit and leaves no ambiguity about the tool's 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?

The description states 'Use this for any support.hpe.com document - release notes, advisories, customer notices, product documentation,' which clearly establishes when to use the tool. It also explains the topic-picking workflow with page and include_all_topics. However, it does not explicitly name alternative sibling tools or state when not to use them, so it stops short of a full 5.

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

get_latest_morpheus_releaseA

Report the newest HPE Morpheus release this server knows about.

Compares the release-notes documents in the server's configured list and returns the highest version, with its publication month and document link.

Important: this reflects the documents the server has been told about, not a live query of everything HPE has published - HPE has no anonymous search API. If you have reason to think a newer release exists, find its release notes with your own web search and read it with get_hpe_document; the appliance's own build version comes from the Morpheus tools, not this one.

product is morpheus-enterprise or morpheus-vm-essentials.

ParametersJSON Schema

Name	Required	Description	Default
`product`	No		morpheus-enterprise

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It clearly states the tool is not a live API query, has no anonymous search access, depends on server configuration, and does not report the appliance's build version. This is unusually transparent about limitations.

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 front-loaded with the tool's purpose, then uses short paragraphs for return behavior and important caveats. Every sentence earns its place, and the structure makes the tool's limitations and alternatives easy to scan.

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

Completeness5/5

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

The description fully describes what the tool returns, how it computes the result, what it cannot do, and when to use alternative tools. There is no output schema, so the stated output fields are necessary and sufficient. Nothing critical is missing for an agent to call this tool 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 schema has zero description coverage, but the description compensates by explicitly naming the two valid product values: 'morpheus-enterprise' or 'morpheus-vm-essentials'. This is essential guidance since the schema itself has no enum or property description.

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: 'Report the newest HPE Morpheus release this server knows about.' It then clarifies the mechanism (compares release-notes documents) and the exact output (highest version, publication month, document link), distinguishing it clearly from the sibling tools that retrieve documents or search the KB.

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 this tool reflects only server-configured documents, not a live HPE query. It then tells the agent exactly what to do if a newer release is suspected: search the web and read the result with get_hpe_document. It also directs appliance build version questions to Morpheus tools, preventing misuse.

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

list_hpe_document_topicsA

List the topics (table of contents) of an HPE document.

Cheaper than reading a whole document when you only need one section - "Fixes" or "New features" of a release notes document, for instance. Accepts a document id or a URL containing one.

ParametersJSON Schema

Name	Required	Description	Default
`document`	Yes

TDQS

A4.2/5.0

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. It discloses the input behavior (accepts document id or URL) and the cost/performance advantage ('cheaper'), but does not describe output structure, pagination, or potential failure modes. It is adequate but not richly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, purposeful sentences. The main purpose is front-loaded, the use case follows naturally, and the input format is stated last. Every sentence earns its place and there is no 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 simple one-parameter read-only tool with no output schema, the description provides the essential context: what it returns (topics/table of contents), when to use it, and how to specify the document. It does not describe the exact return shape, but the tool is simple enough that this is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the single parameter 'document' would otherwise be ambiguous. The description adds crucial meaning: it accepts either a document ID or a URL containing one. This compensates well for the missing schema description, though it could specify more about accepted ID formats.

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 verb ('List') and resource ('topics/table of contents of an HPE document'), and immediately contrasts with reading a whole document, which distinguishes it from the sibling get_hpe_document. The purpose is unambiguous and specific.

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 says to use this tool when you only need one section like 'Fixes' or 'New features', and frames it as a cheaper alternative to reading the full document. It does not explicitly name all sibling alternatives or exclusions, but the when-to-use guidance is clear enough.

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

search_hpe_kbA

Search the HPE Support Center knowledgebase by keyword.

Requires a signed-in HPE account: HPE serves documents anonymously but gates search behind a login. If this returns authentication_required, find the document with your own web search instead - HPE documents are indexed publicly, and search results carry the docId=... you need - then read it properly with get_hpe_document.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`max_results`	No

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and discloses important behavior: login is required, HPE gates search behind authentication, and search results expose docId values. It also names a likely error condition and a recovery path, which is valuable transparency 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 front-loaded with the core purpose and then adds concise, high-value operational guidance. Every sentence earns its place; there is no filler or redundant restating of 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?

For a two-parameter search tool with no annotations and no output schema, the description covers the key context: authentication requirements, likely failure, result hint (docId), and the correct follow-up tool. It does not explain pagination or result formatting, but those are secondary given the simple interface.

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 tells the agent that query is a keyword, adding a little meaning beyond the bare schema property. However, with 0% schema description coverage, max_results is left entirely to the agent to infer from its name and default, so the compensation is only partial.

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') and a clear resource ('HPE Support Center knowledgebase by keyword'). It also references the sibling tool get_hpe_document as the follow-up reader, which helps disambiguate it from related 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 gives clear context for when to use this tool and covers an explicit fallback: if authentication_required is returned, use a web search and then get_hpe_document. It does not explicitly contrast with list_hpe_document_topics, but the search-vs-read distinction is strongly implied.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Sep 9, 2026
- First observedget_hpe_document
- First observedget_latest_morpheus_release
- First observedlist_hpe_document_topics
- First observedsearch_hpe_kb

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.3/5.0

Scored 2026-09-09 17:30 across 4 tools

Disambiguation4/5

Most tools have clearly distinct jobs: searching, reading, listing topics, and checking latest release. The only real ambiguity is that `get_hpe_document` can also return a topic list when called without `page`, which overlaps with `list_hpe_document_topics`, but the descriptions clarify the intended use.

Naming Consistency4/5

All tool names follow a predictable verb-first snake_case pattern: get, list, search. Minor inconsistencies exist, such as `search_hpe_kb` using the abbreviation `kb` and `get_latest_morpheus_release` shifting to a product-specific name, but the overall pattern is still easy to follow.

Tool Count4/5

Four tools is a reasonable size for a focused knowledgebase reader. Each tool has a purpose, though `get_hpe_document` and `list_hpe_document_topics` are slightly redundant in one mode, and the Morpheus-specific release tool is narrower than the rest of the server.

Completeness4/5

The core document workflow is covered: search for documents, list topics, and read page content. Gaps are minor—there is no general browse-by-product tool, and search depends on a signed-in HPE account—but the server documents a workaround and offers a useful release-specific helper.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ragie
com.mcparmory
Ingest, manage, and retrieve documents for RAG-powered AI applications
RAG Systems Databases Knowledge & Memory
2
docs A
com.ntop
Search and query nTop's knowledge base and engineering guides from AI applications.
Search Documentation Access
32
ref-tools-ref-tools-mcpOAuth
ai.smithery
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Documentation Access Developer Tools Code Analysis
21,173
embedded-docs A
ai.byteask
Page-cited retrieval for embedded docs, datasheets, MISRA, CMSIS, and RTOS references.
Embedded system Documentation Access
3223

Related MCP Servers

Adobe Experience League MCP
Documentation Access Search Content Management Systems
vinnyang
F
license
Not graded
quality
D
maintenance
Enables AI assistants to search and fetch documentation content from Adobe Experience League, allowing natural language queries to retrieve Adobe product documentation and articles.
Updated 10 months ago (2025-11-16 03:46 UTC)
-
MCP RAG Server
RAG Systems Vector Databases Knowledge & Memory
0xrdan
A
license
Not graded
quality
C
maintenance
Enables AI assistants to search and retrieve information from your knowledge base using RAG (Retrieval-Augmented Generation) with hybrid search, document indexing, and ChromaDB vector storage.
Updated 9 months ago (2026-01-02 19:31 UTC)
25 npm
MIT
Jamf Docs MCP Server
Documentation Access Search
GET-Technology-Inc
A
license
A
quality
A
maintenance
Provides AI assistants with direct access to Jamf official documentation, enabling them to answer Jamf-related questions by searching, retrieving articles, and browsing product documentation.
Updated 3 days ago (2026-09-18 09:24 UTC)
6
801 npm
3
MIT
enterprise-knowledge
RAG Systems Search Knowledge & Memory
Enesp4rl4k
A
license
Not graded
quality
C
maintenance
Enables AI agents to securely search and ingest corporate documents via MCP, offering hybrid retrieval, PII sanitization, role-based access control, and citation validation.
Updated a month ago (2026-08-25 23:41 UTC)
MIT

HPE Knowledgebase MCP server

Why this exists

Tools

About get_latest_morpheus_release

Install and run

As a service

Wiring it into HPE Morpheus

Behaviour worth knowing

Tests

Versioning

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

About `get_latest_morpheus_release`