What can you do with this server?

The Hermai MCP server lets agents interact with Hermai's schema registry for web workflows. You can: * Look up schemas by domain, task description, category, or verification state. * List public schemas with filtering, pagination, and sorting. * Submit new schema requests via a six-field intake form for missing or problematic workflows. * Classify browser workflows into direct API, hidden endpoint, browser-only, or owner/auth-required. * Check request status using a returned request ID. * Fetch live data (only with a valid HERMAI_API_KEY) by executing registered schemas for read-only retrieval, consuming Hermai credits. Discovery, classification, submission, and status checks do not require an API key; live data fetching does.

How do I use Hermai MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Hermai MCP find schemas for scraping amazon product prices" 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.

Hermai MCP

Official

by hermai-ai

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Hermai MCP

Dedicated Model Context Protocol server for Hermai.

Use this package when an agent runtime supports MCP and should call Hermai as native tools. The Hermai CLI is a separate human/operator tool and is not required for MCP.

Install

Run directly with npx:

npx -y hermai-mcp

Or install globally:

npm install -g hermai-mcp
hermai-mcp

Related MCP server: yellow-pages

MCP Client Config

{
  "mcpServers": {
    "hermai": {
      "command": "npx",
      "args": ["-y", "hermai-mcp"]
    }
  }
}

Optional environment variables:

HERMAI_API_BASE or HERMAI_PLATFORM_URL: API base URL. Defaults to https://api.hermai.ai.
HERMAI_API_KEY or HERMAI_PLATFORM_KEY: API key for authenticated Hermai APIs. Public schema lookup and schema-request intake work without a key. Setting a key also unlocks the fetch_schema execution tool (see below).
HERMAI_FETCH_TIMEOUT_MS: request timeout for fetch_schema. Defaults to 120000 (hosted fetch lanes can run tens of seconds).

Claude Code workflow

Use the local MCP server when you want Claude Code to discover a schema, inspect the available workflow, and make an authenticated read request. Hermai MCP is a local stdio server. It is not a remote Claude connector.

Install Claude Code, then add Hermai to your personal Claude Code configuration:

export HERMAI_API_KEY='hm_sk_...'
claude mcp add --scope user hermai -e HERMAI_API_KEY="$HERMAI_API_KEY" -- npx -y hermai-mcp
unset HERMAI_API_KEY

The key is saved in your local Claude Code configuration. Do not put this command in a repository, shared shell history, or a project scoped MCP configuration.

Confirm that Claude Code can see the server:

claude mcp list

Then start Claude Code and use this two step request:

Use lookup_schema to find a verified public Hermai schema for [the source and task].
Before making a fetch, show me the site, endpoint, required parameters, and whether
the result can be retrieved with fetch_schema.

After you approve the selected workflow:

Use fetch_schema with the site, endpoint, and parameters we selected. Return a short
summary of the records, then show credits_used, credits_remaining, and cached from
the response metadata.

lookup_schema is safe to use without a key. fetch_schema appears only when the key is configured. It reads data through Hermai Cloud and consumes credits for a successful request. Do not give the server browser cookies, bearer tokens, or a request that changes data on another service.

For a full verification checklist and the expected failure paths, see the Claude Code guide.

Tools

Always available (no key required):

lookup_schema — search Hermai schemas by domain, task, category, or verification state.
list_public_schemas — page through public schemas.
submit_schema_request — submit the six-field intake for a brittle browser/API workflow.
classify_browser_workflow — locally classify whether a workflow maps to direct API, hidden endpoint, browser-only, or owner/auth work.
check_schema_request_status — check a schema request status.

Available only when HERMAI_API_KEY (or HERMAI_PLATFORM_KEY) is set:

fetch_schema — execute a registered schema through hosted /v1/fetch and return live data. Read-only data retrieval, and it consumes Hermai credits: a standard call costs 1 credit and some higher cost sites cost 5; only successful calls are billed. Inputs: site, endpoint (resolve both with lookup_schema first; endpoint is case-sensitive), and optional params. The result includes the upstream data plus a meta summary (credits_used, credits_remaining, latency_ms, cached); failures surface the API code and message, plus upgrade_to and upgrade_url when a credit 402 offers an upgrade path. Use it for read workflows only — write/owner-approved workflows go through the Hermai CLI's signed-write path, not this tool.

Never submit cookies, bearer tokens, API keys, session IDs, or private session data through schema-request intake.

Available Tools

5 tools

check_schema_request_statusCheck schema request statusA

Read-onlyIdempotent

Check the status of a previously submitted Hermai schema request. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`request_id`	Yes	Schema request id returned by submit_schema_request.

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds 'Read-only', which is redundant. It does not provide additional behavioral context such as expected results or edge cases, so the value added is minimal.

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, front-loaded sentence with no wasted words. Every word earns its place, making it highly efficient for an AI agent 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?

For a simple read-only check with one parameter and no output schema, the description is mostly complete. However, it could be improved by mentioning what kind of status information is returned, though the absence of an output schema makes this less critical.

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% coverage with a clear description for the single parameter 'request_id' ('Schema request id returned by submit_schema_request'). The tool description does not add further semantic value beyond what the schema already provides, so a baseline score is appropriate.

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 it checks the status of a previously submitted Hermai schema request. It uses a specific verb ('check') and resource ('schema request'), and distinguishes from siblings like 'submit_schema_request' (submission) and 'lookup_schema' (schema lookup).

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

Usage Guidelines4/5

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

The description implies usage after submitting a request ('previously submitted'), providing clear context. However, it does not explicitly mention when not to use or suggest alternatives, which keeps it from a top score.

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

classify_browser_workflowClassify a browser workflowA

Read-onlyIdempotent

Classify a prose workflow as direct API, hidden endpoint, browser-only, or needs owner/auth. Read-only and local.

ParametersJSON Schema

Name	Required	Description	Default
`prose`	Yes	Post, issue, or user request describing the workflow.

TDQS

A4.2/5.0

Behavior5/5

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

Description adds 'Read-only and local' beyond annotations (readOnlyHint, idempotentHint), providing valuable context about mutability and scope. No contradictions.

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?

One concise sentence that front-loads the action and includes all essential information with no superfluous words.

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 simple input (one string) and no output schema, the description adequately explains the classification categories and behavioral traits, though it does not specify the return format explicitly.

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 single parameter 'prose' is fully described in the schema (100% coverage). The description adds a list of example sources but does not significantly enhance meaning beyond the schema.

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 verb 'classify' and the resource 'prose workflow' and lists the four possible output categories, distinguishing it from sibling tools which are schema-related.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives, but the specific task (classifying workflows) and sibling tools (schema lookups) make usage context clear by implication.

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

list_public_schemasList public Hermai schemasA

Read-onlyIdempotent

List public schemas in the Hermai registry with optional filters. Read-only.

ParametersJSON Schema

Name	Required	Description
`q`	No	Free-text search query.
`sort`	No	Sort order, for example trending, recently_verified, or recent.
`limit`	No	Maximum number of schemas to return.
`category`	No	Optional category filter.
`verified`	No	Only return verified schemas.

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's 'Read-only' adds no new behavioral information. The description does not disclose additional traits such as pagination behavior, authentication requirements, or rate limits, but it does not contradict the annotations.

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, front-loaded sentence that immediately conveys the tool's purpose. It has zero wasted words and earns its place by being directly actionable.

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 absence of an output schema, the description does not clarify what information is returned (e.g., schema names, metadata). It adequately covers the tool's input behavior but leaves the output structure implicit, which could cause an agent to misunderstand the result format.

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?

Schema coverage is 100% with descriptions for all five parameters, so the baseline is 3. The description only mentions 'optional filters' generically, adding no specific semantic detail beyond what the schema provides (e.g., it does not explain valid values for 'sort' like 'trending' or 'recently_verified').

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 specifies the action ('List'), the resource ('public schemas'), and the scope ('in the Hermai registry with optional filters'). It effectively distinguishes itself from sibling tools like lookup_schema (which likely targets individual schemas) and submit_schema_request (a write operation).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like lookup_schema or submit_schema_request. It mentions 'optional filters' but does not explain the selection criteria or trade-offs between this and sibling tools.

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

lookup_schemaLook up a Hermai schemaB

Read-onlyIdempotent

Search Hermai for a schema by domain, task, category, or verification state. Read-only.

ParametersJSON Schema

Name	Required	Description
`task`	No	Natural-language task or workflow description.
`domain`	No	Exact domain, for example allbirds.com.
`category`	No	Optional schema category filter.
`verified`	No	Only return verified schemas.

TDQS

B3.4/5.0

Behavior2/5

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

The description repeats the read-only nature already declared in annotations (readOnlyHint, idempotentHint) and provides no additional behavioral details such as search behavior, result limits, or authentication requirements. It does not contradict annotations.

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 extremely concise (12 words) and front-loaded with the core action. Every word is meaningful, and there is no redundancy or fluff.

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 low complexity (4 optional parameters, no output schema) and the presence of annotations, the description is largely adequate. However, it lacks details on the return format (e.g., single schema vs. list) and search matching behavior, which would improve completeness.

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?

All four parameters have clear descriptions in the schema (100% coverage). The description merely lists them without adding usage examples, constraints, or interactions, so it does not add significant value beyond the schema.

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 uses the specific verb 'Search' and lists the filtering dimensions (domain, task, category, verification state), making it clear what the tool does. It also notes it is read-only, distinguishing it from mutation siblings like submit_schema_request.

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

Usage Guidelines2/5

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

The description does not specify when to use this tool versus its siblings (e.g., list_public_schemas) and does not mention any prerequisites or limitations. It only states what it does, offering no guidance on selection context.

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

submit_schema_requestSubmit a schema requestA

Idempotent

Submit the six-field intake for a missing or brittle browser workflow. Never include cookies, API keys, or private session data.

ParametersJSON Schema

Name	Required	Description
`task`	Yes	Recurring task the agent is trying to perform.
`domain`	Yes	Exact domain that agents need data from.
`auth_shape`	Yes	Authentication shape, for example public, anonymous, login required, OAuth, or owner-approved.
`source_url`	No	Optional public thread, issue, or page where this request came from.
`failure_mode`	Yes	What breaks today: selector drift, timeout, captcha, stale values, API shape change, etc.
`output_shape`	Yes	Specific fields or JSON shape the agent needs.
`read_or_write`	Yes	Whether the workflow reads data, writes data, or both.
`idempotency_key`	No	Optional stable key for retry-safe submits.
`requester_agent`	No	Optional agent or builder identifier.
`requester_contact`	No	Optional contact. Do not include secrets.

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false, which partially cover behavioral traits. The description adds a security constraint (avoiding secrets) but does not disclose the outcome of submission (e.g., return value or next steps), which is a gap given the lack of an output schema.

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 consists of two concise, front-loaded sentences. Every word contributes meaning: the first defines the action and target, the second adds critical safety instruction. No unnecessary information.

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?

While the description covers the core action and a key constraint, it lacks context about the submission process (e.g., expected output, how to track the request via sibling tool check_schema_request_status). Given the tool has 10 parameters and no output schema, more detail on post-submission behavior would improve 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?

With 100% schema description coverage, the baseline is 3. The description adds value beyond the schema by emphasizing the required six fields and providing a security constraint that applies to parameters like requester_contact. This guidance helps the agent avoid mistakes.

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 tool's purpose: submitting a six-field intake for missing or brittle browser workflows. It uses a specific verb ('submit') and resource ('schema request'), and it distinguishes itself from sibling tools like lookup_schema and check_schema_request_status which handle different operations.

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

Usage Guidelines4/5

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

The description provides explicit context for when to use the tool ('missing or brittle browser workflow') and gives a security guideline ('Never include cookies, API keys, or private session data'). However, it does not explicitly mention when not to use it or compare with alternatives like lookup_schema for existing schemas.

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. Dates show when Glama detected each change.

5 tool updatesv1.1.1Jul 29, 2026
- First observedcheck_schema_request_status
- First observedclassify_browser_workflow
- First observedlist_public_schemas
- First observedlookup_schema
- First observedsubmit_schema_request

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool serves a clearly distinct purpose: searching schemas, listing public schemas, submitting requests, classifying workflows, and checking request status. No functional overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case, making them predictable and easy to distinguish.

Tool Count5/5

With 5 tools, the server covers the core operations for schema registry and workflow classification without being excessive or minimal.

Completeness4/5

The tool set provides search, list, submit, classify, and status-checking. A minor gap is the lack of a tool to view full details of a submitted request, but the core workflow is complete.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

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

Cralo
ai.cralo
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Agent Orchestration Developer Tools
1
ToolRouter B
io.github.Humanleap
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
471
Plato's Kallipolis A
io.github.handongzhen101-jpg
Read-only MCP tools for AI agent discovery, structured resources, and NIULAI information.
Agent Orchestration AI & Machine Learning
41
AgencyAI Commerce MCP A
io.github.barnaby-coder
AgencyAI's public MCP for service discovery and AI-readiness assessment.
AI & Machine Learning Search Cloud Platforms
31

Related MCP Servers

Hermes Atlas MCP Server
Search Agent Orchestration
bkuri
A
license
A
quality
B
maintenance
Enables AI agents to search, browse, and recommend tools from the Hermes Agent ecosystem directory with zero configuration.
Updated 3 months ago (2026-06-18 06:10 UTC)
8
22
MIT
yellow-pages
RAG Systems Developer Tools
ethank64
F
license
A
quality
D
maintenance
Exposes two MCP tools (discover and execute) that enable agents to query an OpenAPI schema via natural language and execute matched API operations.
Updated 6 months ago (2026-03-18 21:41 UTC)
2
-
Relay
Agent Orchestration Developer Tools
adarshp14
A
license
Not graded
quality
D
maintenance
Enables AI agents to access a unified catalog of tools from various APIs (OpenAPI, GraphQL, MCP, Google Discovery) through the MCP protocol.
Updated 2 months ago (2026-06-29 06:34 UTC)
MIT
toolrouter-mcp
Agent Orchestration AI & Machine Learning Search
Humanleap
A
license
Not graded
quality
C
maintenance
Provides access to over 226 tools and 1,208 skills across web search, image/video generation, SEO, scraping, and more, allowing any MCP-compatible agent to discover, search, and call AI tools via a hosted gateway.
Updated 2 months ago (2026-07-07 19:32 UTC)
27
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hermai-ai/hermai-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server