en es ja ko zh

gotoHuman MCP

Name: gotoHuman MCP
Author: gotohuman

Official

by gotohuman

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Remote

gotoHuman MCP 服务器

gotoHuman 可以轻松地将人工批准添加到 AI 代理和代理工作流程中。
具有可定制批准 UI 的完全管理的异步人机循环工作流程。
享受内置身份验证、webhook、通知、团队功能和不断发展的训练数据集。

使用我们的 MCP 服务器通过 MCP 从您的 AI 工作流请求人工批准，或将其添加到您的 IDE 以帮助集成。

安装

npx @gotohuman/mcp-server

与 Cursor / Claude / Windsurf 一起使用

{
  "mcpServers": {
    "gotoHuman": {
      "command": "npx",
      "args": ["-y", "@gotohuman/mcp-server"],
      "env": {
        "GOTOHUMAN_API_KEY": "your-api-key"
      }
    }
  }
}

获取您的 API 密钥并在app.gotohuman.com设置审批步骤

Related MCP server: LoopIn MCP Server

演示

这是左侧的光标，但它可能是对批准 webhook 做出反应的后台代理。

https://github.com/user-attachments/assets/380a4223-ea77-4e24-90a5-52669b77f56f

工具

`list-forms`

列出所有可用的审查表格。

返回您帐户中所有可用表单的列表，包括有关添加字段的高级信息

`get-form-schema`

获取请求对给定表单进行人工审核时使用的模式。

参数
- formId ：用于获取架构的表单 ID
返回模式，考虑包含的字段及其配置

`request-human-review-with-form`

申请人工审核。邮件将出现在您的 gotoHuman 收件箱中。

参数
- formId ：评论的表单 ID
- fieldData ：表单字段的内容（AI 输出以进行审查、上下文……）和配置。
  需要使用get-form-schema获取此模式
- metadata ：表单提交后，将包含在 webhook 响应中的可选附加数据
- assignToUsers评论的用户电子邮件的可选列表
返回gotoHuman 中评论的链接

发展

# Install dependencies
npm install

# Build the server
npm run build

# For testing: Run the MCP inspector
npm run inspector

在 MCP 客户端本地运行（例如 Cursor / Claude / Windsurf）

{
"mcpServers": {
  "gotoHuman": {
    "command": "node",
    "args": ["/<absolute-path>/build/index.js"],
    "env": {
      "GOTOHUMAN_API_KEY": "your-api-key"
    }
  }
}
}

[!NOTE] 对于 Windows， args路径需要为C:\\<absolute-path>\\build\\index.js

Available Tools

3 tools

get-form-schemaA

Get the schema to use for the 'fields' property when requesting a human review with a form.

ParametersJSON Schema

Name	Required	Description	Default
`formId`	Yes	The form ID to fetch the schema for

TDQS

A4.1/5.0

Behavior3/5

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 describes the tool's purpose and usage context but lacks details on behavioral traits like error handling, rate limits, authentication requirements, or response format. For a read operation with no annotations, this is a moderate gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that efficiently conveys the tool's purpose and usage without redundancy. It is front-loaded with the core function and includes necessary context, making it highly concise and effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description adequately covers purpose and usage. However, it lacks details on behavioral aspects like response format or error conditions, which would be helpful for an agent. It's complete enough for basic use but has room for improvement.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the single parameter 'formId' clearly documented. The description does not add any additional semantic context beyond what the schema provides, such as where to obtain the formId or format examples. Baseline 3 is appropriate when schema coverage is high.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Get the schema') and the precise resource ('for the fields property when requesting a human review with a form'). It explicitly distinguishes this tool from its sibling 'request-human-review-with-form' by indicating it provides the schema needed for that operation, not performing the review itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool: 'to use for the fields property when requesting a human review with a form.' It clearly positions this as a prerequisite step for the sibling tool 'request-human-review-with-form,' providing clear context and distinguishing it from the other sibling 'list-forms.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-formsA

List all available review forms. NOTE: You need to fetch the schema for the form fields first using the get-form-schema tool.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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 discloses a behavioral trait (the prerequisite to use 'get-form-schema' first), which adds useful context beyond basic functionality. However, it doesn't cover other aspects like rate limits, permissions, or return format, leaving some gaps in behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero waste: the first states the purpose, and the second provides critical usage guidance. It is front-loaded with the core function and efficiently adds necessary context, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is complete enough for its purpose. It covers the main action and a key prerequisite, though it could be more comprehensive by mentioning what the output contains or any limitations. Without an output schema, some additional detail on return values might be helpful but isn't strictly required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 lack of inputs. The description doesn't need to add parameter details, and it appropriately focuses on usage context. A baseline of 4 is applied for tools with no parameters, as the description compensates by providing relevant guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('all available review forms'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get-form-schema' beyond mentioning it as a prerequisite, so it doesn't reach the highest level of sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool by specifying a prerequisite: 'You need to fetch the schema for the form fields first using the get-form-schema tool.' This provides clear guidance on usage context and references an alternative tool, meeting the criteria for a top score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

request-human-review-with-formA

Request a human review with a form. NOTE: If you don't have a form ID yet, list all available forms using the list-forms tool first. To know what to pass for fieldData, you need to fetch the schema for the form fields using the get-form-schema tool.

ParametersJSON Schema

Name	Required	Description
`formId`	Yes	The form ID to request a human review for
`fieldData`	Yes	The field data to include in the review request. Note that this is a dynamic schema that you need to fetch first using the get-form-schema tool.
`metadata`	No	Optional additional data that will be incl. in the webhook response after form submission. Incl. everything required to proceed with your workflow.
`assignToUsers`	No	Optional list of user emails to assign the review to

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It mentions that metadata is included in webhook responses and that assignments are optional, adding some behavioral context. However, it lacks details on permissions, rate limits, or what happens after submission (e.g., review workflow), leaving gaps for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by concise prerequisite notes. Every sentence serves a clear purpose—no redundancy or fluff—making it efficiently structured and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description does well by covering prerequisites and parameter nuances. However, as a mutation tool, it could benefit from more details on behavioral outcomes (e.g., review process, error handling), slightly limiting completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that fieldData requires fetching a dynamic schema via get-form-schema and that metadata aids workflow continuity, enhancing understanding beyond the schema's technical definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Request a human review') and the resource ('with a form'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from its siblings (get-form-schema, list-forms) beyond mentioning them as prerequisites, so it lacks full sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: after obtaining a form ID from list-forms and field data schema from get-form-schema. It clearly outlines prerequisites and references alternatives, ensuring proper sequencing and context.

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.

3 tool updatesv1.0.0Jan 2, 2026
- Changedget-form-schema1 field changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
- Changedlist-forms1 field changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
- Changedrequest-human-review-with-form3 fields changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
  - addedInput schema / properties / fieldData / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
  - addedInput schema / properties / metadata / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
3 tool updatesAug 18, 2025
- First observedget-form-schema
- First observedlist-forms
- First observedrequest-human-review-with-form

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Scored 2026-04-18 11:05 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: get-form-schema retrieves schema information, list-forms enumerates available forms, and request-human-review-with-form submits a review request. There is no overlap in functionality, and the descriptions explicitly guide agents on when to use each tool, preventing misselection.

Naming Consistency4/5

The tool names follow a consistent verb-noun pattern with hyphens (e.g., get-form-schema, list-forms, request-human-review-with-form), making them readable and predictable. The minor deviation is that request-human-review-with-form includes a prepositional phrase, but this does not significantly impact consistency.

Tool Count5/5

With 3 tools, this server is well-scoped for its purpose of handling human reviews with forms. Each tool earns its place by covering essential steps: schema retrieval, form listing, and review submission, without being overly sparse or bloated.

Completeness5/5

The tool set provides complete coverage for the domain of requesting human reviews with forms. It includes all necessary CRUD-like operations: retrieving schema (read), listing forms (read), and submitting reviews (create), with no obvious gaps that would cause agent failures in this workflow.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

SiliconBridge
io.github.aataqi-boop
Human-in-the-loop API for AI agents. CAPTCHA, OTP, KYC, and approvals by real humans.
Autonomous Agents Customer Support Security
2
AgentFabric — Human-in-the-Loop Review & Approval B
io.github.enzoduit
Human-in-the-loop review and approval for AI agents. Audit trail, approval policies, native MCP.
Agent Orchestration Security Observability
11
Verifi A
cloud.verifi
Get a real human to verify, decide, or improve an AI agent's work.
AI & Machine Learning Autonomous Agents
42
NeedHuman A
io.github.MariusAure
Human-as-a-Service for AI agents. Delegate tasks that need a real human, get results via API.
Autonomous Agents App Automation
321

Related MCP Servers

vantagate-mcp-server
Aderix
A
license
Not graded
quality
D
maintenance
Human-in-the-Loop authorization gateway for AI Agents. Securely pause MCP workflows and route high-risk actions to human approvers via Slack or Email.
Updated 4 months ago (2026-05-05 19:44 UTC)
85
1
MIT
LoopIn MCP Server
Autonomous Agents AI & Machine Learning
nicholasemccormick
A
license
Not graded
quality
D
maintenance
Enables AI agents to pause execution at critical decision points and request human review before proceeding. Provides tools for creating interrupts, polling for decisions, and managing approvals through a simple REST API interface.
Updated 5 months ago (2026-04-17 01:45 UTC)
11
MIT
final-approval
Autonomous Agents Agent Orchestration
finalapproval
A
license
A
quality
D
maintenance
Human-in-the-loop approval gate for AI agents. Your agent calls submit_approval before any irreversible action; a human reviews on a branded page; a signed webhook fires back with the decision.
Updated 5 months ago (2026-04-19 13:44 UTC)
1
1
MIT
Approval Gate
Agent Orchestration Developer Tools
Keldrik
A
license
Not graded
quality
D
maintenance
Provides a human approval gate for AI agents, enabling interactive inline cards for approving, editing, or rejecting actions before they are executed.
Updated 3 months ago (2026-06-10 00:10 UTC)
MIT

Appeared in Searches

Search for HITL (Human-in-the-Loop or other possible acronyms)