Enables searching Docker documentation to find implementation details, examples, and specifications
Provides access to Node.js documentation search for finding implementation details, examples, and specifications
Allows searching React documentation to find implementation details, examples, and specifications
Click on "Install 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., "@UseKeen Documentation MCP Server search for React documentation on hooks"
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.
MCP Server for the UseKeen API, enabling Claude and other AI assistants to search documentation.
usekeen_package_doc_searchSearch documentation of packages and services to find implementation details, examples, and specifications
Required inputs:
package_name (string): Name of the package or service to search documentation for (e.g. 'react', 'aws-s3', 'docker')
Optional inputs:
query (string): Search term to find specific information within the package/service documentation (e.g. 'file upload example', 'authentication methods')
Returns: Documentation search results with relevant matches, URLs, and snippets
Related MCP server: UseKeen Documentation MCP Server
UseKeen API Key: Get a UseKeen API key from the UseKeen service
Node.js (for NPX installation) or Docker (for Docker installation)
Claude Desktop or VS Code with MCP extension
The easiest way to use this MCP server is via NPX:
npx usekeen-mcpYou can also run the server using Docker:
docker run -e USEKEEN_API_KEY=your_api_key_here mcp/usekeenFor local development or manual installation:
# Clone the repository
git clone <repository-url>
cd usekeen-mcp
# Copy environment file and add your API key
cp .env.example .env
# Edit .env and add your USEKEEN_API_KEY
# Install dependencies
npm install
# Build and run
npm run build
npm startAdd the following to your claude_desktop_config.json:
{
"mcpServers": {
"usekeen": {
"command": "npx",
"args": [
"-y",
"usekeen-mcp"
],
"env": {
"USEKEEN_API_KEY": "your_api_key_here"
}
}
}
}{
"mcpServers": {
"usekeen": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"USEKEEN_API_KEY",
"mcp/usekeen"
],
"env": {
"USEKEEN_API_KEY": "your_api_key_here"
}
}
}
}For manual installation, add the following JSON block to your User Settings (JSON) file in VS Code. You can do this by pressing Ctrl + Shift + P and typing Preferences: Open Settings (JSON).
Optionally, you can add it to a file called .vscode/mcp.json in your workspace. This will allow you to share the configuration with others.
Note that the
mcpkey is not needed in the.vscode/mcp.jsonfile.
{
"mcp": {
"inputs": [
{
"type": "promptString",
"id": "usekeen_api_key",
"description": "UseKeen API Key",
"password": true
}
],
"servers": {
"usekeen": {
"command": "npx",
"args": ["-y", "usekeen-mcp"],
"env": {
"USEKEEN_API_KEY": "${input:usekeen_api_key}"
}
}
}
}
}{
"mcp": {
"inputs": [
{
"type": "promptString",
"id": "usekeen_api_key",
"description": "UseKeen API Key",
"password": true
}
],
"servers": {
"usekeen": {
"command": "docker",
"args": ["run", "-i", "--rm", "mcp/usekeen"],
"env": {
"USEKEEN_API_KEY": "${input:usekeen_api_key}"
}
}
}
}
}We provide two helper scripts to make it easier to run the server:
Local Execution:
# Make the script executable (first time only)
chmod +x run-local.sh
# Run the server locally
./run-local.shDocker Execution:
# Make the script executable (first time only)
chmod +x run-docker.sh
# Run the server in Docker
./run-docker.shBoth scripts will check for a .env file containing your USEKEEN_API_KEY. You can create this file based on the provided .env.example.
Set the USEKEEN_API_KEY environment variable and run the server:
# Install dependencies
npm install
# Build the TypeScript code
npm run build
# Run the server
USEKEEN_API_KEY=your_api_key npm startBuild and run the Docker container with the API key:
# Build the Docker image
docker build -t mcp/usekeen .
# Run the container
docker run -e USEKEEN_API_KEY=your_api_key mcp/usekeenUSEKEEN_API_KEY: Required. Your UseKeen API key for authentication.
If you encounter errors, verify that:
Your UseKeen API key is valid and correctly set in your configuration
You have an active internet connection to reach the UseKeen API
The UseKeen service is currently available
The server always returns MCP-compliant tool results as result.content (array of content blocks). Some clients display a generic error if a custom object is returned instead of content. This server normalizes API responses and also sets isError: true for failures so clients render them correctly. If integrating new tools, ensure they return { content: [{ type: "text", text: "..." }] } and never wrap results under custom keys like { result: { results: [...] } }.
Docker build:
docker build -t mcp/usekeen .This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License.
Search documentation of packages and services to find implementation details, examples, and specifications. The user's query should be as specific as possible to get the best results.
| Name | Required | Description | Default |
|---|---|---|---|
| package_name | Yes | Name of the package or service to search documentation for (e.g. 'react', 'aws-s3', 'docker') | |
| query | Yes | Search term to find specific information within the package/service documentation (e.g. 'file upload example', 'authentication methods') |
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 mentions that queries should be specific for best results, hinting at search behavior, but lacks critical details: it doesn't specify the source of documentation (e.g., official docs, community resources), whether it performs real-time web searches or uses a cached index, potential rate limits, authentication needs, or error handling. For a search tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 and front-loaded: the first sentence states the core purpose, and the second adds usage guidance. Both sentences earn their place by providing essential information without redundancy. However, it could be slightly more structured by explicitly separating purpose from guidelines, but it's efficient overall.
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 context: no annotations, no output schema, 2 parameters with full schema coverage, and no sibling tools, the description is moderately complete. It covers the basic purpose and offers query specificity advice, but it lacks details on behavioral aspects (e.g., search scope, result format, limitations) that would be crucial for an AI agent to use it effectively. Without an output schema, the description doesn't explain return values, which is a gap, but the schema handles parameters well.
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 clear explanations for both parameters: 'package_name' and 'query'. The description doesn't add any additional semantic information beyond what the schema provides (e.g., it doesn't clarify parameter interactions or provide examples not in the schema). According to the rules, with high schema coverage (>80%), the baseline score is 3 even without param info in the description.
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's purpose: 'Search documentation of packages and services to find implementation details, examples, and specifications.' This specifies the verb (search), resource (documentation), and target (packages/services). However, without sibling tools, it cannot demonstrate differentiation from alternatives, so it doesn't reach the highest score.
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 some usage guidance: 'The user's query should be as specific as possible to get the best results.' This implies that vague queries may yield poor results, offering practical advice. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., general web search or other documentation tools), and there are no sibling tools to compare against, so the guidance is limited to query specificity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool has a clear and distinct purpose focused on searching documentation.
A single tool inherently has perfect naming consistency, as there are no other tools to compare it against. The name 'usekeen_package_doc_search' follows a descriptive pattern.
One tool is too few for a server that appears to cover documentation search for packages and services. This minimal set limits functionality and suggests an incomplete or narrow implementation for the domain.
The tool set is severely incomplete for a documentation server. It only provides search functionality, lacking essential operations like browsing documentation categories, retrieving specific documents, or managing documentation updates, which are typical for such domains.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Search @imqueue docs and scaffold typed services & clients from your AI coding agent.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
@latest documentation and code examples to 9000+ libraries for LLMs and AI code editors in a singl…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Use-Keen/usekeen-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
