Skip to main content
Glama
enesjakozh
gotohuman

gotoHuman MCP

Official
by gotohuman
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Remote

gotoHuman MCPサーバー

gotoHuman を使用すると、AI エージェントとエージェント ワークフローに人間による承認を簡単に追加できます。
カスタマイズ可能な承認 UI を備えた、完全に管理された非同期のヒューマンインザループ ワークフロー。
組み込みの認証、Webhook、通知、チーム機能、進化するトレーニング データセットをお楽しみください。

当社の MCP サーバーを使用して、MCP 経由で AI ワークフローから人間による承認をリクエストするか、IDE に追加して統合を支援します。

インストール

npx @gotohuman/mcp-server

カーソル / クロード / ウィンドサーフィンと一緒に使用

{
  "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
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
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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

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

  • LoopIn MCP Server

    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.
    11
    MIT

  • final-approval

    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.
    1
    1
    MIT

  • Approval Gate

    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.
    MIT

Appeared in Searches