Provides full Home Assistant control including reading entity states, calling services, querying history, rendering templates, and resolving rooms/areas.
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., "@ha-mcp turn off the living room lights"
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.
A self-hosted Model Context Protocol server for Home Assistant, in TypeScript. It gives an MCP client (Claude Desktop, Claude Code, Codex CLI, …) the full Home Assistant control surface: read any entity's state, call any service, query history, render templates, and resolve rooms/areas - over a single local stdio connection.
Home Assistant ships an official MCP Server integration, but it's deliberately narrow: it
only exposes the Assist intent layer over entities you've explicitly exposed to voice
assistants - no raw states, no arbitrary service calls, no history, no templates, no area
registry. ha-mcp wraps the documented REST
and WebSocket APIs directly, so
the model can work with everything in your instance.
Related MCP server: HA Vibecode Agent
Tool | What it does |
| List entity states; optional |
| Full state + attributes for one |
| Call any service ( |
| State-change history for an entity over the last N hours |
| Render a Jinja2 template against live state |
| HA version, location, unit system, components |
| The error log, for troubleshooting |
| All areas/rooms |
| Entities in a room, resolving device→area inheritance |
Listing automations is just
ha_get_statesfiltered toautomation.*; triggering one isha_call_service('automation','trigger'). Scenes and scripts work the same way - no separate tools needed.
Node.js ≥ 20
A Home Assistant instance and a long-lived access token (HA → your profile → Security → Long-lived access tokens → Create token).
git clone https://github.com/qubit999/ha-mcp.git
cd ha-mcp
npm install
npm run buildThis produces dist/index.js - the executable the clients launch.
The server reads two environment variables:
Variable | Default | Description |
|
| Base URL of your Home Assistant instance |
| (required) | A long-lived access token |
The same token authenticates both the REST calls and the WebSocket (used for the area
registry). For local development you can drop these in a .env file and run npm run dev.
All three clients launch the server locally over stdio. Use the absolute path to
dist/index.js.
Download the latest ha-mcp.mcpb from the
Releases page (no build step needed), or
build it yourself with npm run bundle.
Then in Claude Desktop: Settings → Extensions → Install Extension… (or just drag
ha-mcp.mcpb into the window). Claude shows a form for Home Assistant URL and
token (the token is masked and stored in your OS keychain), then launches the server
for you. Restarting the app or re-pasting config is not needed.
If you'd rather not bundle, edit the config directly - Settings → Developer → Edit Config
opens the file (path: ~/Library/Application Support/Claude/claude_desktop_config.json -
note the space in "Application Support", so quote it in a shell). Add the block below and
fully quit + relaunch the app:
{
"mcpServers": {
"ha-mcp": {
"command": "node",
"args": ["/Users/alex/ha-mcp/dist/index.js"],
"env": {
"HASS_URL": "http://localhost:8123",
"HASS_TOKEN": "your-long-lived-token"
}
}
}
}claude mcp add ha-mcp \
--scope user \
--env HASS_URL=http://localhost:8123 \
--env HASS_TOKEN=your-long-lived-token \
-- node /Users/alex/ha-mcp/dist/index.jsVerify with claude mcp list / claude mcp get ha-mcp.
Add to ~/.codex/config.toml:
[mcp_servers.ha-mcp]
command = "node"
args = ["/Users/alex/ha-mcp/dist/index.js"]
env = { HASS_URL = "http://localhost:8123", HASS_TOKEN = "your-long-lived-token" }Then ask: "Turn on the kitchen light" or "What's the temperature in the living room?"
A long-lived token grants full control of your Home Assistant (and thus your home). This
server is designed to run locally over stdio - the client launches it as a subprocess; no
network port is opened and the token never leaves your machine. Keep the token out of version
control (the included .gitignore excludes .env). If you scope it into a shared
.mcp.json, use a non-admin HA user or environment variables instead. There is intentionally
no remote/HTTP transport here.
npm run dev # run from source with tsx (+ .env)
npm run build # type-check and emit dist/Tools are thin wrappers over src/ha.ts (REST helpers + a short-lived WebSocket client for
the registries). The WebSocket connection is opened per registry fetch and cached briefly -
there's no long-lived socket to manage.
MIT © qubit999
Call any Home Assistant service. Examples: light.turn_on, climate.set_temperature, automation.trigger, scene.turn_on, media_player.play_media. Pass extra params (brightness, temperature, etc.) in data.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| domain | Yes | ||
| service | Yes | ||
| entity_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It fails to mention side effects, permission requirements, synchronicity, or error handling. For a tool that triggers real-world actions, this is a significant 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 concise at two sentences, front-loading the purpose and then providing examples and a usage hint. It is efficient but could be slightly more 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 complexity (general service caller with 4 parameters, no output schema, no annotations), the description is too minimal. It lacks guidance on the domain/service pattern, optionality of entity_id, and the nature of the response, making it incomplete for an agent to use confidently.
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 0%, so the description must explain parameters. It only addresses the 'data' parameter with a note about extra params. The other parameters (domain, service, entity_id) are not explained, leaving ambiguity despite the examples.
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 'Call any Home Assistant service' and provides specific examples (light.turn_on, climate.set_temperature), which distinguishes it from sibling tools that are all read/get operations.
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 context of use is implied: use when you want to perform an action rather than read. The sibling tools are all query/read functions, so the description's action-oriented purpose provides clear separation. However, it does not explicitly state when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Home Assistant configuration: version, location, unit system, time zone, loaded components.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits beyond the fact it retrieves configuration. It lacks details on read-only nature, authentication, or side effects, but the simplicity reduces concern.
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 sentence, front-loads the action, and lists key fields without any unnecessary verbiage.
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?
For a no-parameter, no-output-schema tool, the description adequately explains what the output contains (version, location, unit system, time zone, loaded components). However, it could mention the response format.
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?
There are no parameters, and schema coverage is 100%, so the baseline is 3. The description adds value by listing what the returned configuration includes, justifying a slightly higher score.
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 tool gets Home Assistant configuration and lists specific fields (version, location, etc.), distinguishing it from sibling tools that handle individual entities or states.
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?
No explicit when-to-use or when-not-to-use guidance is provided, though the description implies it's for global config retrieval, and sibling names hint at alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the entity_ids in a given area/room (by name or area_id), resolving device→area inheritance.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully cover behavioral traits. It mentions 'resolving device→area inheritance', but does not disclose permissions, side effects, or rate limits. More detail on inheritance resolution behavior is needed for safe usage.
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 one sentence of 16 words, with no filler. Every word contributes to explaining the tool's purpose and parameter usage.
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?
For a simple tool with one parameter and no output schema, the description covers the core functionality. However, without annotations, additional details about inheritance resolution behavior and expected output format would increase 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?
The single parameter 'area' has no description in the schema (0% coverage). The description adds that it accepts 'name or area_id', providing essential semantic context beyond the schema's 'string' type, fully compensating for the lack of schema documentation.
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 tool lists entity_ids for a given area by name or area_id, and mentions resolving device-to-area inheritance. It distinguishes from sibling tools like ha_list_areas (which lists areas) and ha_get_entity (detailed entity data).
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 explains how to specify the area (by name or area_id) and implicitly when to use the tool (to get entities in a room/area). However, it does not explicitly state when not to use it or mention alternatives like ha_get_states for all entities, which would be clearer guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full state and attributes of one entity by entity_id (e.g. 'light.kitchen_lights').
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure. It states it returns state and attributes but omits side effects (likely read-only), auth requirements, error handling, or what happens for missing entities.
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?
One sentence with no wasted words. Includes an example inline. Efficiently conveys the core action and parameter usage.
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?
Adequate for a simple read tool, but with no output schema, it would benefit from mentioning the return format (e.g., JSON object). Sibling tools are provided but not referenced in the description.
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?
With 0% schema description coverage, the description compensates by naming the parameter entity_id and providing an example ('light.kitchen_lights'). However, it does not explain constraints like valid entities or format beyond the example.
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 uses a specific verb 'Get' and resource 'full state and attributes of one entity', with an explicit example of entity_id format. It clearly distinguishes from sibling tools like ha_get_states which presumably return multiple entities.
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?
No guidance on when to use this tool vs alternatives such as ha_get_states or ha_get_history. There are no exclusions or context about when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Home Assistant error log (plain text) for troubleshooting.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states 'Get' implying read-only, but does not disclose idempotency, rate limits, or potential side effects. Minimal disclosure for a simple retrieval 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?
A single, front-loaded sentence with no waste. Every word adds value – verb, resource, format, purpose.
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?
For a zero-parameter retrieval tool with no output schema, the description covers the returned content (plain text error log) and usage intent. Could mention if the log is truncated or its typical size, but sufficient for its simplicity.
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?
There are zero parameters and the schema covers 100% trivially. Per guidelines, 0 params baseline is 4, and the description adds no parameter meaning beyond the schema.
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 specifies 'Get the Home Assistant error log (plain text) for troubleshooting' – a clear verb and resource with stated purpose. It distinguishes from siblings like ha_get_config or ha_get_states, but does not explicitly contrast them.
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 phrase 'for troubleshooting' implies usage context, but there is no explicit when-to-use, when-not-to-use, or alternative guidance. This is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get state-change history for an entity over the last N hours (default 24).
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| entity_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the time range and default but omits whether the operation is read-only, any side effects, or authentication needs. The read-only nature is implied but not stated.
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?
A single sentence with 12 words, front-loading the purpose and key parameter. No unnecessary information.
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, output schema, or sibling guidance, the description covers the basic purpose but lacks return format details, pagination, or permission context. It is minimally adequate for a simple retrieval tool.
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?
With 0% schema coverage, the description adds meaning by linking 'entity' to entity_id and explaining the 'hours' parameter as the time range with a default. However, it does not explicitly state that entity_id is required or describe expected formats.
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 tool retrieves state-change history for an entity over a configurable time range. The verb 'Get' and resource 'state-change history' are specific, and the default of 24 hours adds precision. This distinguishes it from siblings like ha_get_entity (current state) and ha_get_states (all current states).
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 implies usage for historical data retrieval but does not explicitly indicate when to use this tool versus alternatives like ha_get_entity for current state. No exclusions or alternative names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Home Assistant entity states. Optionally filter by domain (e.g. 'light', 'sensor') and/or area (room name or area_id).
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | ||
| domain | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately implies a read operation by stating 'list,' but lacks details on behavior like whether it returns all states without filters, or any limitations.
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?
Single, front-loaded sentence with no unnecessary words; every part earns its place.
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 output schema and 0% schema coverage, the description omits critical details about return format (structure of each state), which an agent needs to correctly parse results.
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?
Despite 0% schema description coverage, the description adds meaningful context for parameters: domain examples and area clarification (room name or area_id), though could be more precise for domain values.
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?
Description clearly states the tool lists Home Assistant entity states with optional filtering by domain and area, distinguishing it from siblings like ha_get_entity (single) and ha_get_history.
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?
Implied usage for listing states with optional filters but no explicit guidance on when to use this tool versus alternatives like ha_get_entities_by_area or ha_get_history, and no when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all areas/rooms defined in Home Assistant.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 only states the basic operation without any behavioral details such as authentication requirements, rate limits, or the structure of the returned data. For a read-only list operation, some transparency is implied, but the description does not explicitly confirm safety or format.
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 sentence of 10 words, front-loading the verb 'List'. It is perfectly concise with no wasted words, and every word earns its place.
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 has no parameters and no output schema, the description minimally fulfills completeness by stating the scope. However, it does not describe the return format (e.g., list of names, objects) or any edge cases. For a simple tool, this is adequate but not fully complete.
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 zero parameters, and the schema coverage is 100% (no undocumented params). Per baseline rules, this scores a 4. The description adds no parameter information, which is acceptable since there are none.
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?
Description clearly states the tool's purpose: listing all areas/rooms in Home Assistant. It uses a specific verb ('List') and resource ('areas/rooms'), and is distinct from sibling tools that deal with services, config, or entities.
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 does not explicitly state when to use this tool vs alternatives, but the purpose is clear enough that the agent can infer it's for getting a complete list of areas. Sibling tools like ha_get_entities_by_area serve different purposes, so ambiguity is low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a Home Assistant Jinja2 template and return the result. Example: "{{ states('sensor.outside_temperature') }}".
| Name | Required | Description | Default |
|---|---|---|---|
| template | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It only states rendering and return of result, omitting error handling (e.g., invalid template), available variables, side effects (likely read-only), and output format. Minimal 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 concise with two sentences and an immediate example. No superfluous information, efficient and front-loaded.
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 (one required string parameter, no output schema), the description is minimally adequate but lacks details on return format, error behavior, and available Jinja2 context. Could be more complete.
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 coverage is 0%, so description must compensate for parameter meaning. The description adds an example but does not explain the 'template' parameter beyond being a string. Lacks details on valid syntax, variable scope, or constraints.
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 tool renders a Home Assistant Jinja2 template and returns the result, with a concrete example. This verb+resource combination is unique among siblings, none of which perform template rendering.
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 implies usage for template evaluation but does not provide explicit when-to-use or when-not-to-use guidance. There are no alternative tools for template rendering, making the usage context clear but lacking exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0ha_call_serviceha_get_configha_get_entities_by_areaha_get_entityha_get_error_logha_get_historyha_get_statesha_list_areasha_render_templateEach tool has a clearly distinct purpose: service calls, configuration retrieval, entity queries by area or ID, error logs, history, state listing, area listing, and template rendering. No overlap in functionality.
All tools follow a consistent 'ha_{verb}_{noun}' pattern with underscores, using verbs like 'call', 'get', 'list', and 'render'. The prefix 'ha_' identifies the server, and naming is predictable.
With 9 tools covering essential Home Assistant operations (service calls, state queries, configuration, history, error logs, areas, and template rendering), the count is well-scoped for an MCP server without being excessive.
The tool set covers core Home Assistant interactions: calling any service, retrieving states, config, history, error logs, and area information. The inclusion of template rendering adds flexibility. No obvious gaps for common tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
A TypeScript MCP server for Home Assistant, enabling programmatic management of entities, automati…
Self-hosted MCP gateway: turn any API, database or MCP server into AI connectors — no code.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/qubit999/ha-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server