Skip to main content
Glama
enesjakozh
gotohuman

gotoHuman MCP

Official
by gotohuman
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Remote

gotoHuman MCP 서버

gotoHuman을 사용하면 AI 에이전트와 에이전트 워크플로에 인간 승인을 쉽게 추가할 수 있습니다.
사용자 정의 가능한 승인 UI를 갖춘 완전 관리형 비동기 인간 참여 워크플로입니다.
내장된 인증, 웹후크, 알림, 팀 기능 및 진화하는 교육 데이터 세트를 활용해 보세요.

MCP 서버를 사용하여 MCP를 통해 AI 워크플로에 대한 인간 승인을 요청하거나 IDE에 추가하여 통합을 지원하세요.

설치

지엑스피1

커서/클로드/윈드서프와 함께 사용

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

app.gotohuman.com 에서 API 키를 받고 승인 단계를 설정하세요.

Related MCP server: LoopIn MCP Server

데모

이것은 왼쪽의 커서이지만, 승인 웹훅에 반응하는 백그라운드 에이전트일 수도 있습니다.

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

도구

list-forms

사용 가능한 모든 리뷰 양식을 나열하세요.

  • 추가된 필드에 대한 고급 정보를 포함하여 계정에서 사용 가능한 모든 양식의 목록을 반환합니다 .

get-form-schema

주어진 양식에 대한 인간 검토를 요청할 때 사용할 스키마를 가져옵니다.

  • 매개변수

    • formId : 스키마를 가져올 폼 ID

  • incl. 필드와 해당 구성을 고려하여 스키마를 반환합니다 .

request-human-review-with-form

직접 검토를 요청하세요. gotoHuman 받은 편지함에 표시됩니다.

  • 매개변수

    • formId : 리뷰에 대한 양식 ID

    • fieldData : 콘텐츠(검토할 AI 출력, 컨텍스트 등)와 양식 필드에 대한 구성입니다.
      이에 대한 스키마는 get-form-schema 사용하여 가져와야 합니다.

    • metadata : 양식 제출 후 웹훅 응답에 포함될 선택적 추가 데이터

    • 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