Novel Factory MCP
Server Details
Generates complete long-form novels from one premise: outline, prose, self-review, ZIP delivery.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 12 of 12 tools scored. Lowest: 2.8/5.
Each tool targets a distinct function: authentication, password reset, LLM config, novel generation, chapter writing, review, job status, subscription, helpdesk, and health check. No overlapping purposes.
Most tools follow a verb_noun pattern (e.g., configure_llm, generate_novel, register_account). However, 'helpdesk' and 'ping' deviate as single-word names, introducing mild inconsistency.
12 tools cover the full lifecycle of a novel writing service: auth, configuration, core writing, review, status tracking, subscription, and support. Neither too few nor too many.
Core workflows are covered: account management, LLM config, novel generation, chapter writing/review, and job status. Minor gaps exist (e.g., no explicit tool to pause/cancel a generation job), but overall complete.
Available Tools
12 toolsconfigure_llmAInspect
配置用户的 LLM API 端点。
写作系统需要调用大模型来生成内容。用户在此配置自己的 API Key 和模型， 服务端代为调用（API Key 加密存储，不出域）。
支持所有 OpenAI 兼容接口（DeepSeek / OpenAI / 本地 Ollama 等）。
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | 模型名称，如 deepseek-v4-pro | |
| api_key | No | API 密钥（将被加密存储） | |
| base_url | No | API 基础 URL，如 https://api.deepseek.com/v1 | |
| _auth_token | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses that the API key is encrypted and the server makes calls on behalf of the user. However, it does not mention whether configuration is persistent, if it overwrites previous settings, or any other behavioral traits like rate limits or update behavior.
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 three concise sentences in Chinese, each providing critical information: purpose, use case, and compatibility. It is front-loaded with the main action and adds detail without fluff. Every sentence earns its place.
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 an output schema (not shown) and 4 parameters with no required ones, the description is reasonably complete. It explains the purpose, usage context, security (encryption), and supported providers. Minor gap: it does not mention if the configuration persists or if it updates existing settings, but overall it is adequate.
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 schema has 4 parameters with 75% description coverage (missing _auth_token). The description adds value beyond schema by stating that the tool supports all OpenAI-compatible interfaces (DeepSeek, OpenAI, Ollama), which informs the model and base_url parameters. It also mentions API key encryption, supplementing the schema's description of api_key.
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: '配置用户的 LLM API 端点' (configure the user's LLM API endpoint). It specifies the verb 'configure' and the resource 'LLM API endpoint', distinguishing it from sibling tools like login or chapter writing. The context of writing system needing to call large models is also provided.
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 explains when to use this tool: when the user needs to configure their own API key and model for the writing system to call large models. It mentions support for OpenAI-compatible interfaces. However, it does not explicitly state when not to use or provide alternatives among siblings, which are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgot_passwordAInspect
忘记密码 — 向注册邮箱发送一次性重置验证码。
Send a one-time password reset code to the registered email. 收到邮件后用 reset_password 工具完成重置 / then use reset_password to finish.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | 注册时绑定的邮箱 / the email bound at registration | ||
| language | No | 客户语言代码（决定邮件语言）/ customer's language (email language) | zh |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description states that a one-time code is sent via email, which is adequate for a password reset tool. However, it does not disclose potential rate limiting, error handling for invalid emails, or idempotency, leaving some behavioral gaps.
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 bilingual, two sentences plus a note, with no wasted words. It front-loads the purpose and immediately provides the next step.
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 password reset tool, the description covers the essential purpose and parameters. The existence of an output schema reduces the need to describe return values. It could mention what happens if the email is not found, but overall it's complete.
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%, and the description adds meaningful context: email must be the registered one and language determines email language. This goes beyond the schema descriptions.
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 sends a one-time password reset code to the registered email, distinguishing it from sibling tools like reset_password, login_account, and register_account. The verb+resource combo is specific and accurate.
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 explicitly indicates usage when the user has forgotten a password and provides the sequential step to use reset_password. It lacks explicit when-not-to-use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_novelAInspect
一句话高概念 → 全书自动写作（四阶段流水线）。
这是本系统的核心入口。输入小说的一句话高概念（如「赘婿从离婚开始」）， 系统自动完成章纲生成→正文写作→审校质检→输出打包全流程。
| Name | Required | Description | Default |
|---|---|---|---|
| concept | Yes | 一句话高概念（必填），如「现代修仙：程序员穿越成宗门底层代码维护工」 | |
| language | No | 写作语言代码（zh/en/ja/ko/es/fr/de/pt/ru 等）。客户用什么语言， 就传对应代码，全书将以该语言写作。zh/en 完整适配，其他语言 beta。 | zh |
| _auth_token | No | ||
| quality_tier | No | 品质档位，78(基础) 或 95(极致)，需匹配订阅套餐 | |
| chapter_count | No | 总章节数，默认100，范围1-2000 | |
| content_detail | No | 补充内容描述（可选），世界观、主角设定、风格偏好等 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes the four-stage pipeline and mentions subscription matching for quality_tier, providing some behavioral context. However, it does not disclose rate limits, authentication requirements (despite the _auth_token parameter), or any destructive aspects.
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 two sentences, front-loaded with the key action, and each sentence provides essential context without fluff. It is appropriately sized and 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's complexity (full novel generation) and the presence of an output schema (not shown), the description covers the pipeline stages and core entry point adequately. It lacks details on error handling or response structure, but the output schema likely covers that.
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 high (83%), so the schema already documents most parameters. The description adds context about the pipeline but does not add significant meaning beyond what the schema provides. Baseline 3 is appropriate.
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 action ('自动写作') and resource ('全书'), distinguishing it from siblings like write_chapter and review_chapter by positioning it as the core entry point for full novel generation with a four-stage pipeline.
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 as the main entry for full novel generation, but does not explicitly state when to use alternatives or when not to use this tool. Sibling tools like write_chapter and review_chapter suggest single-chapter operations, but no direct comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_job_statusCInspect
查询写作任务的执行状态和结果。
异步任务通过此工具查询进度、获取下载链接。
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | 任务 ID（由 generate_novel 返回） | |
| _auth_token | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It mentions querying status and results, but lacks details on authentication needs, rate limits, error handling, or polling behavior. The description is sparse on behavioral traits.
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?
Two sentences, concise and front-loaded. No redundancy. Could benefit from better structure, but it is efficient for the information provided.
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 status-checking tool with an output schema (not shown), the description covers essential aspects: querying progress and getting download links. However, it lacks details on polling behavior or error conditions, and the absence of output schema visibility limits completeness assessment.
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 50% (job_id has a decent description, _auth_token lacks one). The description adds no additional meaning to parameters beyond indicating the tool's purpose. It does not compensate for the undocumented parameter.
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 is for querying status and results of writing tasks, with emphasis on async tasks. It uses specific verb and resource, implying the tool's purpose is well-defined. Though it does not explicitly differentiate from siblings like 'generate_novel' or 'write_chapter', the context makes it distinct.
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 limited guidance: it says it's for async tasks to query progress and get download links. There is no explicit when-to-use, when-not-to-use, or alternatives. The sibling list includes related tools, but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subscription_infoAInspect
查询当前账户的订阅状态和用量信息。
返回当前套餐、到期时间、本月用量等。 无需付费墙——所有登录用户均可调用。
| Name | Required | Description | Default |
|---|---|---|---|
| _auth_token | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly implies the tool is read-only and accessible, but it does not disclose any potential side effects, rate limits, or data freshness. The description is adequate but not thorough.
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 highly concise: two sentences that front-load the purpose, then list outputs and access condition. No wasted words.
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 output schema exists, the description does not need to detail return fields. However, it fails to document the single input parameter, which is a significant gap. The tool is simple, so completeness is partially achieved.
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 one optional parameter '_auth_token' with 0% documentation coverage in the schema. The description does not mention this parameter at all, leaving its purpose and usage entirely unexplained.
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: query subscription status and usage information. It specifies the return values (current plan, expiration, monthly usage) and distinguishes itself from sibling tools by its unique 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 includes an explicit accessibility note: 'No paywall – all logged-in users can call,' which helps the agent understand when to use the tool. However, it does not provide explicit when-not-to-use guidance or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
helpdeskAInspect
智能客服 — 回应客户关于服务使用、下载、连接、套餐等问题的专业咨询。
当客户询问以下任何话题时调用此工具：
下载地址 / 文件在哪里 / 怎么拿到小说
连接不上 / 超时 / 网络错误
多少钱 / 套餐 / 升级 / 退款
报错了 / 失败了 / 为什么不行
怎么用 / 第一次 / 使用教程
LLM 配置 / API Key / 模型设置
月限 / 用量 / 配额
品质 / 标准模式 vs 极致模式 区别
此工具返回结构化的专业回复文本，智能体可直接转述给客户。
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | No | 关联的任务 ID（可选，用于查询具体任务的下载地址等） | |
| question | Yes | 客户的自然语言问题（必填） | |
| _auth_token | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
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 states that the tool returns 'structured professional reply text' that the agent can directly relay, which hints at a read-only behavior. However, it does not explicitly disclose whether the tool is destructive, requires authentication, or has rate limits, leaving some ambiguity.
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 front-loaded with a clear summary and uses bullet points for specific guidance, making it structured and easy to scan. While it is somewhat lengthy, every sentence serves a purpose in defining the tool's scope, resulting in efficient communication.
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 that an output schema is present, the description does not need to explain return values. It adequately covers the tool's purpose and usage guidelines. It lacks details on error handling or edge cases, but for a helpdesk tool with a comprehensive list of topics, it is sufficiently complete.
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 three parameters with 67% description coverage. The description does not add significant meaning beyond what the schema already provides for the 'question' parameter, and it does not elaborate on 'job_id' or '_auth_token'. With moderate schema coverage, the description meets the baseline but does not compensate for the undocumented parameter.
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 is a smart customer service that responds to professional inquiries about service usage, downloads, connections, plans, etc. It lists specific topics like download addresses, connection issues, pricing, errors, tutorials, LLM configuration, usage limits, and quality modes, making the purpose very specific and distinguishable from sibling tools.
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 explicitly says 'Call this tool when the customer asks about any of the following topics' and enumerates eight categories of queries. This provides clear context for when to use the tool, though it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
login_accountAInspect
登录账户 — 返回访问令牌与当前套餐状态。
Log in and get an access token plus current subscription status.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | 客户语言代码 / customer's language code | zh |
| password | Yes | 密码 / password | |
| username | Yes | 用户名 / username |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It adds context about the return value (token + subscription) but does not mention error conditions, rate limits, or side effects.
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 with two sentences in bilingual format. It is front-loaded and contains no unnecessary words, though bilingual may slightly bloat.
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 presence of an output schema, the description provides adequate information: purpose and key return values. Missing error handling details but acceptable.
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%, baseline is 3. The description does not add any additional meaning beyond the schema parameter descriptions.
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 logs in and returns an access token plus subscription status. It uses a specific verb and resource, and distinguishes from siblings like register_account.
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 logging in, but does not provide explicit guidance on when to use versus alternatives such as register_account or forgot_password.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pingAInspect
健康检查 — 验证 MCP 服务是否正常运行。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool performs a health check, implying it is safe and non-destructive, but does not disclose return values or behavioral nuances. Moderate transparency.
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, consisting of two short phrases that are front-loaded and directly state the purpose. Every word earns its place with zero redundancy.
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 is a simple ping with no parameters and an existing output schema (per context signals), the description is largely complete. It could mention what the output indicates (e.g., success/failure), but the output schema likely covers that. Slightly above minimal.
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?
There are zero parameters, so the input schema covers 100%. With no parameters, the description does not need to add parameter semantics; a baseline of 4 is appropriate.
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 '健康检查 — 验证 MCP 服务是否正常运行' which means 'Health check — Verify whether the MCP service is running normally.' It uses a specific verb ('verify') and resource ('MCP service'), and distinguishes from siblings as no other tool is a health check.
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 checking service availability, but provides no explicit guidance on when to use versus alternatives or any prerequisites. It is adequate but lacks direct instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_accountAInspect
注册新账户 — 客户在对话中直接开户，无需网页。
Register a new account directly in the chat. After registration the tool returns an access token; keep it and pass it as _auth_token in later calls.
| Name | Required | Description | Default |
|---|---|---|---|
| No | 邮箱（可选但强烈建议填写，用于找回密码）/ email, strongly recommended for password recovery | ||
| language | No | 客户使用的语言代码（如 zh/en/ja），影响回复文案 / customer's language code | zh |
| password | Yes | 密码（至少6位）/ password, min 6 chars | |
| username | Yes | 用户名（2-50字符）/ username, 2-50 chars |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral transparency. It reveals that the tool returns an access token and that it is for chat-based registration. However, it does not mention idempotency, destructiveness, or authorization requirements. This is adequate but not thorough.
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, with no unnecessary words. It delivers the core purpose and a critical post-usage instruction in a clear structure. It earns its place.
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?
The tool has an output schema, so the description doesn't need to explain return values. The description mentions the key output (access token). It lacks a note about potential side effects (e.g., does registration trigger an email?). However, for a registration tool, the description is largely complete.
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 schema already has 100% description coverage with bilingual details. The tool description does not provide additional parameter-level insight, so the baseline 3 is appropriate. It doesn't detract but doesn't add value either.
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 uses specific verb 'register' and resource 'account', clearly indicating the tool's purpose. It also adds context that registration happens directly in chat, distinguishing it from other account-related tools like login_account or forgot_password.
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 gives clear guidance on what to do after using the tool (keep and use the token). It implicitly suggests use for new customers, but it does not explicitly compare to login_account or other siblings. Still, it provides actionable post-call instructions, which is valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reset_passwordBInspect
用邮件验证码重置密码（验证码一次性、限时有效）。
Reset the password with the emailed one-time code.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | 客户语言代码 / customer's language code | zh |
| reset_code | Yes | 邮件里收到的重置验证码 / the reset code from the email | |
| new_password | Yes | 新密码（至少6位）/ new password, min 6 chars |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the code is one-time and time-limited, which is useful behavioral context. However, it does not mention any side effects (e.g., automatic login) or state what happens on failure.
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?
Highly concise with two sentences covering both Chinese and English. The key action and constraint are front-loaded. Could be slightly more efficient by combining languages, but no wasted content.
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?
Adequate for a simple tool with output schema present. Missing mention of prerequisite that a reset code must have been requested via 'forgot_password' and error conditions.
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 baseline is 3. The description adds no extra parameter semantics beyond what the schema already provides (e.g., 'reset code from email', 'min 6 chars').
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 resets a password using an emailed one-time code. However, it does not explicitly differentiate from the sibling tool 'forgot_password', which likely initiates the reset process.
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 explicit guidance on when to use or when not to use this tool. It implies the user must have received a code, but does not mention prerequisites or alternatives like 'forgot_password'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
review_chapterAInspect
对已写章节进行审校和质量检查。
多维度质量审查 + [Premium] 结构连贯性复核。 返回评分、问题列表和修改建议。
| Name | Required | Description | Default |
|---|---|---|---|
| _auth_token | No | ||
| chapter_text | Yes | 待审校的章节正文文本 | |
| quality_tier | No | 审校深度 78(基础) 或 95(全面) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions multi-dimensional review and premium structural check, but does not explicitly state if it modifies content, requires authentication, or has side effects.
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?
Two concise sentences front-loading the main purpose and outputs. No wasted words.
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?
With an output schema present and description covering return values (scores, issues, suggestions), it provides sufficient context for a review tool. Minor gap: no mention of limitations or prerequisites.
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 67% with two parameters described. Description adds context about review quality tiers but does not fully compensate for the undocumented _auth_token parameter or clarify parameter behavior beyond schema.
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?
Description clearly states it reviews and checks quality of existing chapters, returning scores, issues, and suggestions. It distinguishes from sibling tools like write_chapter and generate_novel.
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?
Usage is implied for reviewing after writing, but no explicit guidance on when to use versus alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
write_chapterBInspect
写作单章正文。
根据提供的章纲卡片或上下文摘要，调用用户配置的 LLM 生成单章正文。
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | 写作语言代码（zh/en/ja 等），客户用什么语言就传什么 | zh |
| _auth_token | No | ||
| outline_card | No | 章纲卡片 JSON 字符串（含 title/summary/key_events 等） | |
| quality_tier | No | 品质档位 78 或 95 | |
| chapter_number | Yes | 章节号（必填） | |
| context_summary | No | 前文摘要（用于承接上文） |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool calls an LLM and uses provided inputs, but does not mention potential side effects (e.g., overwriting existing content), authentication needs, rate limits, or whether the operation is synchronous or asynchronous. The behavioral insight is minimal.
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 two short sentences, front-loading the core purpose. Every word is necessary, no redundancy. Excellent 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 existence of an output schema (which covers return values) and the tool's moderate complexity, the description covers the basic function. However, it lacks information on error handling, prerequisites (e.g., user must configure LLM), and how it interacts with other tools. It is minimally complete.
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 high (83%), with most parameters already described. The description adds marginal value by mentioning that the tool uses an outline card or context summary, but this is already reflected in the schema. No additional meaning is provided beyond what the schema offers.
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 writes a single chapter text based on an outline card or context summary, using a user-configured LLM. However, it does not differentiate from the sibling 'generate_novel', which may also write chapters, reducing clarity slightly.
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 versus alternatives like 'generate_novel' or 'review_chapter'. The description only implies usage when an outline card or context summary is available, but lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!