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., "@Jokes By Api Ninjas tell me 3 jokes"
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.
用于访问 Jokes By Api Ninjas API 的 MCP 服务器。
EMCP 是一个强大的 MCP 服务器管理平台，让您无需手动配置即可快速使用各种 MCP 服务器！
🌐 访问 EMCP 平台
📝 注册并登录账号
🎯 进入 MCP 广场，浏览所有可用的 MCP 服务器
🔍 搜索或找到本服务器（bach-jokes_by_api_ninjas）
🎉 点击 "安装 MCP" 按钮
✅ 完成！即可在您的应用中使用
✨ 零配置：无需手动编辑配置文件
🎨 可视化管理：图形界面轻松管理所有 MCP 服务器
🔐 安全可靠：统一管理 API 密钥和认证信息
🚀 一键安装：MCP 广场提供丰富的服务器选择
📊 使用统计：实时查看服务调用情况
立即访问 EMCP 平台 开始您的 MCP 之旅！
Related MCP server: Jokes MCP Server
这是一个 MCP 服务器，用于访问 Jokes By Api Ninjas API。
PyPI 包名: bach-jokes_by_api_ninjas
版本: 1.0.0
传输协议: stdio
pip install bach-jokes_by_api_ninjaspip install -e .# 运行（uvx 会自动安装并运行）
uvx --from bach-jokes_by_api_ninjas bach_jokes_by_api_ninjas
# 或指定版本
uvx --from bach-jokes_by_api_ninjas@latest bach_jokes_by_api_ninjaspython server.py# 安装
pip install bach-jokes_by_api_ninjas
# 运行（命令名使用下划线）
bach_jokes_by_api_ninjas此 API 需要认证。请设置环境变量:
export API_KEY="your_api_key_here"变量名 | 说明 | 必需 |
| API 密钥 | 是 |
| 不适用 | 否 |
| 不适用 | 否 |
编辑 Cursor MCP 配置文件 ~/.cursor/mcp.json:
{
"mcpServers": {
"bach-jokes_by_api_ninjas": {
"command": "uvx",
"args": ["--from", "bach-jokes_by_api_ninjas", "bach_jokes_by_api_ninjas"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}编辑 Claude Desktop 配置文件 claude_desktop_config.json:
{
"mcpServers": {
"bach-jokes_by_api_ninjas": {
"command": "uvx",
"args": ["--from", "bach-jokes_by_api_ninjas", "bach_jokes_by_api_ninjas"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}此服务器提供以下工具:
v1jokesAPI Ninjas Jokes API endpoint.
端点: GET /v1/jokes
参数:
limit (string): How many results to return. Must be between 1 and 30. Default is 1.
传输协议: stdio
HTTP 客户端: httpx
MIT License - 详见 LICENSE 文件。
此服务器由 API-to-MCP 工具生成。
版本: 1.0.0
API Ninjas Jokes API endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many results to return. Must be between 1 and 30. Default is 1. |
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 only states it's an 'API endpoint', which implies a read operation but does not specify what it returns (e.g., random jokes, categories), rate limits, authentication needs, or error handling. This leaves critical behavioral traits undocumented.
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, efficient sentence with no wasted words. However, it is under-specified rather than concise—it lacks necessary detail about the tool's function, which slightly reduces its effectiveness despite the brevity.
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 annotations, no output schema, and a simple parameter, the description is incomplete. It fails to explain what the tool does, what it returns, or key behaviors, making it inadequate for an agent to use effectively. The high schema coverage does not compensate for these 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 input schema has 100% description coverage for its single parameter 'limit', detailing its type, range, and default. The description adds no parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.
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 'API Ninjas Jokes API endpoint' is tautological—it restates the tool name 'v1jokes' without specifying what the tool actually does. It lacks a clear verb (e.g., 'fetch', 'retrieve') and resource (e.g., 'jokes'), failing to distinguish from any siblings (though none exist). This is minimally better than a tautology like 'Jokes' but still vague.
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. The description does not mention any context, prerequisites, or alternatives, leaving the agent with no information about appropriate usage scenarios. This is a complete lack of guidance.
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. Dates show when Glama detected each change.
v1.0.0v1jokesWith only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly defined as accessing the Jokes API endpoint, leaving no room for confusion or misselection.
A single tool inherently exhibits perfect naming consistency, as there are no other tools to compare against. The name 'v1jokes' follows a clear pattern that includes versioning and the domain, which is appropriate for its purpose.
A single tool is too few for most practical server purposes, as it limits functionality to a single endpoint. This feels thin and restrictive, especially for a domain like jokes where multiple operations (e.g., fetching by category, rating, or type) might be expected.
The tool surface is severely incomplete for a jokes domain. It only provides access to a single API endpoint without support for common operations like filtering by category, type, or rating, which are typical in joke APIs. This will likely cause agent failures when trying to perform varied tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Get a random dad joke or search by keyword to fit any moment. Retrieve specific jokes by ID for re…
Jokes MCP — wraps JokeAPI v2 (free, no auth)
Dad Jokes MCP — wraps icanhazdadjoke.com (free, no auth)
API Ninjas MCP — wraps the multi-endpoint API Ninjas data API (api-ninjas.com)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BACH-AI-Tools/jokes_by_api_ninjas'
If you have feedback or need assistance with the MCP directory API, please join our Discord server