Skip to main content
Glama
gotohuman

gotoHuman MCP

Official
by gotohuman

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-server

Use with Cursor / Claude / Windsurf

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

Install MCP Server

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 use

    • fieldData: Content (AI-output to review, context,...) and configuration for the review template's fields.
      The schema for this needs to be fetched with get-form-schema

    • config: Configuration for the review template. Optional. The schema for this needs to be fetched with get-form-schema

    • title: Optional title shown in the inbox and notifications

    • webhookUrl: 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 same runId on every review in the same run. If workflow is sent without runId (even {}), or for manual triggers, gotoHuman creates a runId and returns it as workflowRunId for subsequent requests.

      • runName: Optional display name for the run (can be set or updated on any step)

      • prevSteps: Array of reviewIds 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 submission

    • assignToUsers: Optional list of user emails to assign the review to

  • Returns reviewId, reviewLink, and optionally workflowRunId when 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 inspector

Run 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"
    }
  }
}
}
NOTE

For Windows, theargs path needs to be 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
NameRequiredDescriptionDefault
formIdYesThe 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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault
formIdYesThe form ID to request a human review for
fieldDataYesThe 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.
metadataNoOptional additional data that will be incl. in the webhook response after form submission. Incl. everything required to proceed with your workflow.
assignToUsersNoOptional 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.

  1. 3 tool updatesv1.0.0
    • 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"
        +}
  2. 3 tool updates
    • First observedget-form-schema
    • First observedlist-forms
    • First observedrequest-human-review-with-form

TDQS

A4.3/5.0

Scored 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

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • 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.
    85
    1
    MIT
  • 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.
    11
    MIT
  • 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.
    1
    1
    MIT
  • 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.
    MIT