gotoHuman MCP
OfficialThe gotoHuman MCP Server facilitates async human-in-the-loop approvals in AI workflows with the following capabilities:
List Available Review Forms: Fetch all available review forms in your account.
Obtain Form Schema: Retrieve schema details for fields in a specific form.
Request Human Review: Submit a request for human approval with form data, optional metadata, and user assignments.
Integration with IDEs: Easily add the server to development environments like Cursor, Claude, or Windsurf.
Built-In Features: Utilize built-in auth, webhooks, notifications, and team collaboration tools.
Training Dataset: Leverage an evolving dataset to improve the system over time.
Supports installation and building of the MCP server through npm package management, with commands for dependencies, building, and running the inspector.
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., "@gotoHuman MCPrequest a human review for this blog post draft using the 'content-review' form"
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.
gotoHuman MCP Server
gotoHuman makes it easy to add human approvals to AI agents and agentic workflows.
A fully-managed async human-in-the-loop workflow with a customizable approval UI.
Enjoy built-in auth, webhooks, notifications, team features, and an evolving training dataset.
Use our MCP server to request human approvals from your AI workflows via MCP or add it to your IDE to help with integration.
Installation
npx @gotohuman/mcp-serverUse with Cursor / Claude / Windsurf
{
"mcpServers": {
"gotoHuman": {
"command": "npx",
"args": ["-y", "@gotohuman/mcp-server"],
"env": {
"GOTOHUMAN_API_KEY": "your-api-key"
}
}
}
}Get your API key and set up an approval step at app.gotohuman.com
Related MCP server: LoopIn MCP Server
Demo
This is Cursor on the left, but this could be a background agent that also reacts to the approval webhook.
https://github.com/user-attachments/assets/380a4223-ea77-4e24-90a5-52669b77f56f
Tools
list-forms
List all available review templates.
Returns a list of all available review templates in your account incl. high-level info about the added fields
get-form-schema
Get the schema to use when requesting a human review for a given review template.
Params
formId: The review template ID to fetch the schema for
Returns the schema, considering the incl. fields and their configuration
request-human-review-with-form
Request a human review. Will appear in your gotoHuman inbox.
Params
formId: The ID of the review template to usefieldData: Content (AI-output to review, context,...) and configuration for the review template's fields.
The schema for this needs to be fetched withget-form-schemaconfig: Configuration for the review template. Optional. The schema for this needs to be fetched withget-form-schematitle: Optional title shown in the inbox and notificationswebhookUrl: Optional webhook URL for this request (when the review template has no default webhook)workflow: Optional object linking this review to a multi-step agentic workflow:runId: Unique ID for the current workflow run. Use the samerunIdon every review in the same run. Ifworkflowis sent withoutrunId(even{}), or for manual triggers, gotoHuman creates arunIdand returns it asworkflowRunIdfor subsequent requests.runName: Optional display name for the run (can be set or updated on any step)prevSteps: Array ofreviewIds from previous gotoHuman review steps (omit on the first step)
metadata: Optional additional data that will be incl. in the webhook response after review template submissionassignToUsers: Optional list of user emails to assign the review to
Returns
reviewId,reviewLink, and optionallyworkflowRunIdwhen gotoHuman assigned a new workflow run
Development
# Install dependencies
npm install
# Build the server
npm run build
# For testing: Run the MCP inspector
npm run inspectorRun locally in MCP Client (e.g. Cursor / Claude / Windsurf)
{
"mcpServers": {
"gotoHuman": {
"command": "node",
"args": ["/<absolute-path>/build/index.js"],
"env": {
"GOTOHUMAN_API_KEY": "your-api-key",
"GOTOHUMAN_AGENT_ID": "your-agent-id"
}
}
}
}For Windows, theargs path needs to be C:\\<absolute-path>\\build\\index.js
Available Tools
3 toolsget-form-schemaA
Get the schema to use for the 'fields' property when requesting a human review with a form.
| Name | Required | Description | Default |
|---|---|---|---|
| formId | Yes | The form ID to fetch the schema for |
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 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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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 updates
v1.0.0- Changed
get-form-schema1 field changed- removed
Input schema / additionalPropertiesRemoved value: -false
- Changed
list-forms1 field changed- removed
Input schema / additionalPropertiesRemoved value: -false
- Changed
request-human-review-with-form3 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / properties / fieldData / propertyNamesAdded value: +{ + "type": "string" +} - added
Input schema / properties / metadata / propertyNamesAdded value: +{ + "type": "string" +}
3 tool updates
- First observed
get-form-schema - First observed
list-forms - First observed
request-human-review-with-form
TDQS
Scored across 3 tools
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.
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.
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.
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
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
Human-in-the-loop API for AI agents. CAPTCHA, OTP, KYC, and approvals by real humans.
Human-in-the-loop review and approval for AI agents. Audit trail, approval policies, native MCP.
Get a real human to verify, decide, or improve an AI agent's work.
Human-as-a-Service for AI agents. Delegate tasks that need a real human, get results via API.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceHuman-in-the-Loop authorization gateway for AI Agents. Securely pause MCP workflows and route high-risk actions to human approvers via Slack or Email.851MIT
- AlicenseNot gradedqualityDmaintenanceEnables 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.11MIT
- AlicenseAqualityDmaintenanceHuman-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.11MIT
- AlicenseNot gradedqualityDmaintenanceProvides a human approval gate for AI agents, enabling interactive inline cards for approving, editing, or rejecting actions before they are executed.MIT