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., "@Humanizer APIs MCP Server humanize this technical text to make it more conversational"
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.
用于访问 Humanizer Apis API 的 MCP 服务器。
EMCP 是一个强大的 MCP 服务器管理平台，让您无需手动配置即可快速使用各种 MCP 服务器！
🌐 访问 EMCP 平台
📝 注册并登录账号
🎯 进入 MCP 广场，浏览所有可用的 MCP 服务器
🔍 搜索或找到本服务器（bach-humanizer_apis）
🎉 点击 "安装 MCP" 按钮
✅ 完成！即可在您的应用中使用
✨ 零配置：无需手动编辑配置文件
🎨 可视化管理：图形界面轻松管理所有 MCP 服务器
🔐 安全可靠：统一管理 API 密钥和认证信息
🚀 一键安装：MCP 广场提供丰富的服务器选择
📊 使用统计：实时查看服务调用情况
立即访问 EMCP 平台 开始您的 MCP 之旅！
Related MCP server: swagger-mcp-server
这是一个 MCP 服务器，用于访问 Humanizer Apis API。
PyPI 包名: bach-humanizer_apis
版本: 1.0.0
传输协议: stdio
pip install bach-humanizer_apispip install -e .# 运行（uvx 会自动安装并运行）
uvx --from bach-humanizer_apis bach_humanizer_apis
# 或指定版本
uvx --from bach-humanizer_apis@latest bach_humanizer_apispython server.py# 安装
pip install bach-humanizer_apis
# 运行（命令名使用下划线）
bach_humanizer_apis此 API 需要认证。请设置环境变量:
export API_KEY="your_api_key_here"变量名 | 说明 | 必需 |
| API 密钥 | 是 |
| 不适用 | 否 |
| 不适用 | 否 |
编辑 Cursor MCP 配置文件 ~/.cursor/mcp.json:
{
"mcpServers": {
"bach-humanizer_apis": {
"command": "uvx",
"args": ["--from", "bach-humanizer_apis", "bach_humanizer_apis"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}编辑 Claude Desktop 配置文件 claude_desktop_config.json:
{
"mcpServers": {
"bach-humanizer_apis": {
"command": "uvx",
"args": ["--from", "bach-humanizer_apis", "bach_humanizer_apis"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}此服务器提供以下工具:
easy_use_humanizerEasy use
端点: POST /humanizer
basic_modelBasic model (lightweight, useful)
端点: POST /humanizer/basic
multi_languagesBest model for multi languages
端点: POST /humanizer/language
传输协议: stdio
HTTP 客户端: httpx
MIT License - 详见 LICENSE 文件。
此服务器由 API-to-MCP 工具生成。
版本: 1.0.0
Basic model (lightweight, useful)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 'lightweight' and 'useful' which are subjective traits that don't reveal concrete behaviors like whether it's read-only, destructive, requires authentication, has rate limits, or what kind of output to expect. 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 extremely concise ('Basic model (lightweight, useful)') but under-specified rather than efficiently informative. While it's brief, it fails to convey essential information about the tool's purpose and usage, making this conciseness come at the cost of clarity.
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 lack of annotations and output schema, the description is incomplete for understanding this tool. It doesn't explain what the tool does, when to use it, what behavior to expect, or what it returns. For even a simple tool, users need to know its function and output, which are missing here.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter information, and it appropriately doesn't mention any parameters. This meets the baseline expectation for a parameterless tool.
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 'Basic model (lightweight, useful)' is vague and tautological. It restates the tool name 'basic_model' without specifying what action it performs or what resource it operates on. The parenthetical adds some characteristics but doesn't clarify the actual purpose or function.
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 about when to use this tool versus the sibling tools 'easy_use_humanizer' or 'multi_languages'. The description mentions 'lightweight' and 'useful' but doesn't explain in what contexts or for what tasks this tool is appropriate compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Easy use
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. 'Easy use' gives no insight into what the tool does, whether it's read-only or destructive, its authentication needs, rate limits, or any other behavioral traits, making it completely opaque.
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?
While 'Easy use' is brief, it is under-specified rather than concise. The two words fail to convey meaningful information, making the description inefficient and lacking in structure, as it doesn't front-load essential details.
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 lack of annotations, no output schema, and a vague description, the description is incomplete. It provides no context on the tool's function, behavior, or output, failing to compensate for the missing structured data, which is inadequate even for a zero-parameter tool.
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 tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description does not add or detract from parameter semantics, meeting the baseline of 4 for zero-parameter tools.
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 'Easy use' is a tautology that merely restates the tool name 'easy_use_humanizer' without specifying what the tool actually does. It provides no verb, resource, or distinct purpose, failing to differentiate from sibling tools like 'basic_model' or 'multi_languages'.
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 offers no guidance on when to use this tool versus alternatives, such as 'basic_model' or 'multi_languages'. There is no mention of context, prerequisites, or exclusions, leaving the agent with no usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Best model for multi languages
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 but fails completely. It doesn't indicate whether this is a read or write operation, what kind of output to expect, any performance characteristics, or behavioral constraints. The phrase 'Best model' suggests some kind of evaluation or selection, but no actual behavioral information is provided.
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 extremely concise (4 words) but suffers from under-specification rather than effective brevity. While it's front-loaded with the core claim ('Best model for multi languages'), it lacks the necessary substance to be truly helpful. The conciseness comes at the cost of meaningful information, making this more sparse than efficiently structured.
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 tool has no parameters, no annotations, and no output schema, the description is incomplete for understanding what the tool actually does. While zero parameters reduces complexity, the description fails to explain the tool's function, behavior, or output. The agent cannot determine what 'Best model for multi languages' means operationally - is this a recommendation system, a translation tool, or something else entirely?
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 tool has 0 parameters with 100% schema description coverage, so the baseline score is 4. The description doesn't need to compensate for any parameter documentation gaps since there are no parameters to document. The description's mention of 'multi languages' could be seen as providing context about what the tool operates on, but this is minimal value given the zero-parameter nature.
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 'Best model for multi languages' is vague and tautological - it essentially restates the tool name 'multi_languages' with minimal additional information. It doesn't specify what action the tool performs (is it selecting a model? evaluating models? translating?), nor does it distinguish from sibling tools like 'basic_model' or 'easy_use_humanizer'. The description lacks a clear verb+resource combination that would indicate 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of context, prerequisites, or comparison to sibling tools. The agent receives no information about appropriate use cases, making it impossible to determine when this tool should be selected over 'basic_model' or 'easy_use_humanizer'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tools have overlapping and unclear purposes: 'basic_model' and 'easy_use_humanizer' both seem to target general humanization tasks without clear differentiation, and 'multi_languages' might overlap with the others in multilingual contexts. The vague descriptions ('lightweight, useful', 'Easy use') provide little help in distinguishing them, leading to potential misselection.
Naming is inconsistent with mixed conventions: 'basic_model' uses snake_case, 'easy_use_humanizer' mixes snake_case with a compound name, and 'multi_languages' uses snake_case but lacks a clear verb pattern. There is no predictable naming scheme across the set, making it harder for agents to infer tool purposes from names alone.
With 3 tools, the count is borderline for a server named 'Humanizer APIs MCP Server', which suggests a broader scope. This feels thin as it may not cover essential humanization operations (e.g., text formatting, localization, or specific transformations), but it's not severely mismatched like having only one tool.
Inferred domain is text humanization or localization, but the tool set has significant gaps: there are no clear CRUD operations (e.g., create, update, delete humanized content), no specific input/output handling tools, and the vague tools don't cover a complete workflow. This will likely cause agent failures due to missing core functionalities.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hire verified humans for real-world tasks via API or MCP. 14 tools, free API key.
One API for 100+ AI video, image, music and speech models.
Turn any task into the right API calls: discover, evaluate, and integrate public APIs.
Human-in-the-loop API for AI agents. CAPTCHA, OTP, KYC, and approvals by real humans.
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/bachai-humanizer-apis'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
