yiGmMk/mcp-server
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., "@yiGmMk/mcp-serversearch for latest AI news"
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
学习写 mcp server
安装 (cline)
Installing via Smithery
To install mcp-server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @yiGmMk/mcp-server --client claude前置依赖
• Python 3.12 or newer • uv package manager
没有安装uv的,请参考文档uv 安装文档
macos或linux可使用如下命令安装
curl -LsSf https://astral.sh/uv/install.sh | shwindwos,在powershell下安装
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"配置文件
优先使用下面这种配置方式
{
"mcpServers": {
"yiGmMk/mcp-server": {
"command": "uv",
"args": [
"--directory",
"/path/to/your/mcp-server",
"run",
"main.py"
],
"env": {
"JINA_API_KEY": "jina_api_key,请从https://jina.ai/reader获取",
"GOOGLE_AI_STUDIO_KEY": "Google AI Studio api key,请从https://aistudio.google.com/apikey获取",
"PYTHONIOENCODING": "utf-8"
},
"disabled": false,
"autoApprove": []
}
}
}或使用venv(增加环境变量配置)
{
"mcpServers": {
"yiGmMk/mcp-server": {
"command": "uv",
"args": [
"run",
"/path/to/your/mcp-server/main.py"
],
"env": {
"VIRTUAL_ENV": "/path/to/your/mcp-server/.venv",
"JINA_API_KEY": "jina_api_key,请从https://jina.ai/reader获取",
"GOOGLE_AI_STUDIO_KEY": "Google AI Studio api key,请从https://aistudio.google.com/apikey获取",
"PYTHONIOENCODING": "utf-8"
},
"disabled": false,
"autoApprove": []
}
}
}Related MCP server: Eyes-MCP
jina.ai
jina.ai提供的各种工具,如搜索,读取网页...
TODO
发布到 https://smithery.ai/server/@yiGmMk/mcp-server/tools dockerfile构建成功,但是mcp服务在docker中运行后立即退出,导致无法使用,相关issue: 1.MCP within a Docker Container exits, regardless of lifespan
Available Tools
4 toolsfetchB
使用 r.jina.ai 读取 URL 并获取其内容
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 需要抓取的网页url |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description only mentions using r.jina.ai but lacks disclosure on read-only nature, error handling, rate limits, or output format. Insufficient for safe invocation.
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, front-loaded with purpose, no extraneous 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?
For a simple 1-param tool with no output schema, description is minimally sufficient but lacks details on expected output format or constraints.
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 100% so parameter meaning is clear from schema. Description adds minimal value ('get content') beyond the parameter 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 verb-resource-action: using r.jina.ai to read a URL and get its content. It distinguishes from siblings (search, translate) as a fetch operation.
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 alternatives (search, translate). No when-not or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchA
使用 s.jina.ai 搜索网络并获取 SERP,Reader 就会搜索网络并返回前五个结果及其 URL 和内容,每个结果都以干净、LLM 友好的文本显示。这样,您就可以始终让您的 LLM 保持最新状态,提高其真实性,并减少幻觉。不支持用作翻译
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | 搜索关键词 |
TDQS
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 explains the tool returns clean, LLM-friendly text of top 5 results, which is helpful, but omits details on rate limits, authentication, or error handling.
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 relatively concise and front-loaded, but includes an unnecessary mention about translation, which slightly undermines 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 simple tool (one parameter, no output schema), the description adequately explains the return format (top 5 results with URLs and content). It is sufficient for an agent to understand the tool's basic 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 coverage is 100% with a single parameter 'q' described as '搜索关键词'. The description does not add deeper semantics beyond the schema, meeting the baseline expectation.
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 it searches the web and returns the top 5 results with URLs and content, distinguishing it from siblings like fetch (specific URL) and translate (translation). The mention of '不支持用作翻译' adds clarity but is tangential.
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 to keep LLM updated and reduce hallucinations, but lacks explicit guidance on when to use vs. alternatives. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
translateB
使用 gemini 翻译文本,中英文互译
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | 需要翻译的文本 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It only states the translation action and language pair, omitting behavioral traits such as authentication needs, rate limits, side effects, or what the output looks like. This is insufficient for a write-like 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?
The description is a single, concise sentence that delivers the core purpose without fluff. However, it is slightly too brief, missing potentially valuable details, but the essential 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?
Given the simplicity of the tool (1 parameter, no output schema, no annotations), the description still lacks completeness. It does not explain the return format, error conditions, or handle any edge cases, making it insufficient for an agent to fully understand the tool's 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?
The only parameter 'content' is described in the input schema as '需要翻译的文本'. The tool description does not add any additional semantics beyond that, so baseline 3 is appropriate given 100% schema coverage.
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 translates text using Gemini for Chinese-English bidirectional translation. It specifies the verb 'translate', the resource 'text', and the language pair, distinguishing it from the sibling tool 'translate_deepl'.
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 usage for Chinese-English translation with Gemini, but does not explicitly state when to use this tool over the sibling 'translate_deepl' or provide any exclusions or context about 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.
translate_deeplB
使用 deepl 翻译,支持多种语言互译
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | 需要翻译的文本 | |
| source_lang | Yes | 当前语言,source language,支持: AR,BG,CS,DA,DE,EL,EN-GB,EN-US,ES,ET,FI,FR,HU,ID,IT,JA,KO,LT,LV,NB,NL,PL,PT-BR,PT-PT,RO,RU,SK,SL,SV,TR,UK,ZH,ZH-HANS,ZH-HANT | |
| target_lang | Yes | 目标语言,target language,支持:AR,BG,CS,DA,DE,EL,EN-GB,EN-US,ES,ET,FI,FR,HU,ID,IT,JA,KO,LT,LV,NB,NL,PL,PT-BR,PT-PT,RO,RU,SK,SL,SV,TR,UK,ZH,ZH-HANS,ZH-HANT |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose any behavioral traits such as authentication requirements, rate limits, or error handling.
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 clear sentence with no redundant 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?
Lacks details about output format, usage context, or prerequisites, which is insufficient given no output schema and no annotations.
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 does not add meaning beyond what the schema already provides for the parameters.
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 it uses DeepL translation and supports multiple languages, distinguishing it from sibling tool 'translate' which may use a different engine.
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 versus alternatives like 'translate' 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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
4 tool updates
v0.1.0- First observed
fetch - First observed
search - First observed
translate - First observed
translate_deepl
TDQS
The tools fetch and search are clearly distinct. However, the two translation tools (translate and translate_deepl) have overlapping purposes, and agents may struggle to choose between them without strong preferences for Gemini vs. DeepL.
All tool names are lowercase and follow a predictable verb pattern. 'translate_deepl' uses a suffix to specify the engine, which is consistent with the naming scheme.
With 4 tools, the server is on the smaller side but covers its intended scope (fetch, search, translate). It is not overly sparse and could reasonably be expanded with additional utilities.
The server covers fetching URLs, searching the web, and translating with two engines. There is minor duplication in translation tools, and no summarization or extraction tools, but the core functionality is present.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
An MCP server that gives your AI access to the source code and docs of all public github repos
An MCP server that integrates with Discord to provide AI-powered features.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Related MCP Servers
- AlicenseBqualityDmaintenanceAn MCP server that provides access to Jina AI's powerful web services (page reading, web search, fact checking) through Claude.317828MIT
- AlicenseNot gradedqualityBmaintenanceA research MCP server that enables AI agents to query the internet using multiple sources like SearXNG, GitHub, Reddit, and YouTube, and returns synthesized answers with citations.MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that integrates with AI models to provide web search capabilities through a single, easy-to-use tool interface.225MIT
- AlicenseBqualityDmaintenanceMCP server providing search, extract, map, and crawl tools powered by Tavily for real-time web data access.412MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/yiGmMk/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server