Allows reading the GraphQL schema and executing allowed queries and mutations against the Nhost GraphQL API.
Quickstart • Website • Docs • Blog • X • Discord • Ask Nhost Guru (third party, unofficial)
Nhost is an open source Firebase alternative with GraphQL, built with the following things in mind:
Open Source
GraphQL
SQL
Great Developer Experience
Nhost consists of open source software:
Database: PostgreSQL
Instant GraphQL API: Hasura
Authentication: Auth
Storage: Storage
Serverless Functions: Node.js (JavaScript and TypeScript)
Nhost CLI for local development
MCP server built into the CLI, for AI coding assistants
Visit https://docs.nhost.io for the complete documentation.
Related MCP server: Vibgrate AI Context
Sign in to Nhost.
Create Nhost app.
Done.
The Nhost CLI is the easiest way to start developing locally. It sets up a local environment that tracks database migrations and Hasura metadata.
Install the CLI:
macOS / Linux: brew install nhost/tap/nhost or curl -sSL https://raw.githubusercontent.com/nhost/nhost/main/cli/get.sh | bash
Nix: nix profile install github:nhost/nhost#cli
npm / pnpm / Yarn / Bun: npm install -D @nhost/cli,
pnpm add -D @nhost/cli, yarn add -D @nhost/cli, or
bun add -d @nhost/cli
Start building:
nhost login
nhost init
nhost upRead the full CLI Quickstart guide.
Connect your AI assistant (MCP):
The CLI ships with a Model Context Protocol (MCP) server. Your assistant can read the GraphQL schema, run the queries and mutations you allow, update Nhost Cloud project configuration, search the Nhost docs, and in local development manage metadata, permissions, and migrations. Works with Claude Code, Codex, Gemini CLI, Cursor, and other MCP clients.
claude mcp add nhost nhost mcp startSee the MCP Server docs for other clients and access settings.
Since Nhost is 100% open source, you can self-host the whole Nhost stack. Check out the example docker-compose file to self-host Nhost.
Install the @nhost/nhost-js package and start building your app:
import { createClient } from '@nhost/nhost-js'
const nhost = createClient({
subdomain: 'your-project',
region: 'eu-central-1'
})
await nhost.auth.signInEmailPassword({
email: 'user@example.com',
password: '<password>'
})
await nhost.graphql.request({
query: `
query GetUsers {
users {
id
displayName
email
}
}
`
})Nhost is frontend agnostic, which means Nhost works with all frontend frameworks.
Start developing locally with the Nhost CLI
Connect AI assistants to your projects with the Nhost MCP server
First and foremost: Star and watch this repository to stay up-to-date.
Also, follow Nhost on GitHub Discussions, our Blog, and on X. You can chat with the team and other members on Discord and follow our tutorials and other video material at YouTube.
This repository, and most of our other open source projects, are licensed under the MIT license.
Here are some ways of contributing to making Nhost better:
Try out Nhost, and think of ways to make the service better. Let us know here on GitHub.
Join our Discord and connect with other members to share and learn from.
Send a pull request to any of our open source repositories on Github. Check out our contribution guide for more details about how to contribute. We're looking forward to your contribution!
Get GraphQL schema for an Nhost project running in the Nhost Cloud.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | role to use when executing queries. Keep in mind the schema depends on the role so if you retrieved the schema for a different role previously retrieve it for this role beforehand as it might differ | |
| queries | No | list of queries to fetch | |
| summary | No | only return a summary of the schema | |
| mutations | No | list of mutations to fetch | |
| subdomain | Yes | Project to get the GraphQL schema for. Required when service is `project` |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered without the description's help. The description adds almost nothing behavioral beyond the 'Nhost Cloud' scoping phrase – it does not mention that results are filtered/truncated by the default summary flag or that the schema varies by role.
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 zero filler and no repetition. It is efficient, though arguably over-terse for a five-parameter tool whose output shape is unexplained.
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?
With no output schema, the description carries the burden of explaining what comes back, and it says nothing about the summary-vs-full return shape that the schema hints at. For a tool whose output varies by role and by summary flag, this leaves an agent guessing about the response.
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 100%, so the schema already documents role, subdomain, queries, mutations and summary in detail. The description adds no parameter semantics of its own, which is the expected baseline when the schema does the heavy lifting.
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?
States a specific verb and resource: 'Get GraphQL schema for an Nhost project.' An agent knows what it retrieves (schema) and against what (Nhost Cloud project). However, it does not differentiate itself from near-siblings like manage-graphql or graphql-query, and the annotation title's 'various services' scope is broader than the description's Nhost-project scope.
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?
There is no when-to-use guidance: nothing says whether this is for discovery before composing queries, nor when to prefer it over graphql-query or manage-graphql. The role-parameter note about re-fetching per role is the only workflow hint, and it lives in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a GraphQL query against a Nhost project. This tool is useful to query and mutate data. If you run into issues executing queries, retrieve the schema again in case the schema has changed. If you get an error indicating the query or mutation is not allowed the user may have disabled them in the server, don't retry and tell the user they need to enable them when starting nhost's mcp
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | role to use when executing queries. Keep in mind the schema depends on the role so if you retrieved the schema for a different role previously retrieve it for this role beforehand as it might differ | |
| query | Yes | graphql query to perform | |
| userId | No | Overrides X-Hasura-User-Id in the GraphQL query/mutation. Credentials must allow it (i.e. admin secret must be in use) | |
| subdomain | Yes | Project to perform the GraphQL query against | |
| variables | No | variables to use in the query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful non-structured behavior: mutations are possible, schema may drift between calls, and permission errors are terminal (do not retry). It stops short of describing what data can be destroyed or auth requirements beyond the userId note in the schema.
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?
Front-loaded with the core purpose, followed by two conditional failure-handling sentences. Every sentence carries operational value, though the error-handling prose is slightly dense and could be tightened.
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?
There is no output schema and the tool is destructive/open-world with five parameters, so the description carries extra burden. It handles failure modes well but says nothing about the shape of results, pagination, or what mutating calls may alter, leaving gaps for an agent that must reason about consequences.
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 100%, so the schema already documents role, query, userId, subdomain, and variables. The description adds no parameter-level guidance (no query syntax, variable format, or enum meaning for subdomain), so the baseline 3 is appropriate.
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 states a specific verb and resource: execute a GraphQL query against an Nhost project, and widens scope to 'query and mutate data'. It differentiates itself somewhat by pointing to schema retrieval, but never names the get-schema or manage-graphql siblings explicitly, so sibling routing is only implied.
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?
Gives clear operational context: use it to query and mutate data, re-retrieve the schema if execution fails, and if a not-allowed error appears, do not retry and instead tell the user to enable queries/mutations. No explicit 'use X instead of Y' comparison, but the when-to-use and failure-handling conditions are concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Nhost documentation pages. Use this tool to discover available documentation pages and their topics. Optionally group pages by section for a structured overview.
| Name | Required | Description | Default |
|---|---|---|---|
| grouped | No | Show pages organized by top-level section | |
| summary | No | Show page descriptions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the read-only, side-effect-free nature is covered. The description adds only that grouping is optional and yields a 'structured overview'; it says nothing about pagination, volume of results, or rate limits beyond what annotations provide.
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?
Three short sentences, front-loaded with the action and resource, with no filler. The final sentence about optional grouping is useful but could be trimmed; overall it is tight.
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 zero-required-parameter listing tool with no output schema, the description conveys what is returned (documentation pages and topics) and the optional grouping behavior. It is nearly complete, missing only explicit routing guidance versus sibling tools.
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 100%, so both parameters are already documented in the schema, establishing a baseline of 3. The description loosely mirrors the parameters ('group pages by section', '...and their topics') but adds no format, default, or interaction detail 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?
States a specific verb and resource ('List all Nhost documentation pages') and clarifies the discovery intent. It does not explicitly distinguish itself from siblings like search or read_page, so it stops short of a 5.
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?
'Use this tool to discover available documentation pages and their topics' implies an exploration/discovery scenario, which is adequate. However, it never says when to prefer this over the sibling tools search or read_page, and states no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query GraphQL's management endpoints on an Nhost project running. This tool is useful to
manage hasura metadata, migrations, permissions, remote schemas, database migrations,
etc. It also allows to interact with the underlying database directly.
* Before using this tool always describe in natural languate what you are about to do.
## Metadata changes
* When changing metadata ALWAYS use the /apis/migrate endpoint
* Always perform a bulk request to avoid
having to perform multiple requests
* The admin user always has full permissions to everything by default, no need to configure
anything
## Schema changes
* Before performing any schema changes describe the changes in natural language
* Before performing any database schema changes, always check the current state of the database
* When performing database schema changes, always follow existing patterns in the database schema
* When making database schema changes, always do it via the /apis/migrate endpoint
* Always provide a down migration
* Always track new tables
* Always track new foreign keys as relationships
* Never modify the database schema directly via SQL commands, always use the /apis/migrate endpoint
## Roles
* Roles need to be added to the table auth.roles, if requested to add a new role for an
application always do it via a migration
## Data changes
* Before adding/changing/modifying data confirm with the user if the change should be done
using a migration via the /apis/migrate endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The body for the HTTP request | |
| path | Yes | The path for the HTTP request | |
| subdomain | Yes | Project to perform the GraphQL management operation against |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, yet the description adds materially more: describe intent in natural language first, checking current DB state before schema changes, mandatory down migrations, tracking new tables/foreign keys, and user confirmation before mutating data. This is unusually rich disclosure of risk and side effects beyond the structured hints.
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?
Purpose is front-loaded, but the body is a long flat bullet list that repeats the /apis/migrate instruction four times and includes tangential process notes (admin user permissions, adding roles to auth.roles) that do not help an agent invoke the tool. The safety content is justified; the redundancy and operational trivia are not.
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?
There is no output schema, so response handling is left implicit, and the tool's relationship to graphql-query is never clarified. For a destructive, open-world HTTP proxy the description nonetheless covers endpoints, preconditions, and migration policy well enough to call it safely.
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 100%, so the baseline is 3; the description adds real value by naming the concrete path values to use (/apis/migrate) and constraining the request body to migration/metadata payloads. It still says nothing about body format (JSON structure, bulk request shape) or how path relates to the local-only subdomain enum.
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 first sentence states a verb and resource (query GraphQL management endpoints on an Nhost project) and the following paragraph enumerates what is managed: Hasura metadata, migrations, permissions, remote schemas, and direct database interaction. However, it never distinguishes itself from the overlapping siblings graphql-query and get-schema, and calling it 'Query' understates that path+body make it a general HTTP executor for destructive 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?
Extensive when/when-not rules are provided: always use /apis/migrate for metadata and schema changes, never modify schema via raw SQL, always provide down migrations, confirm data changes with the user first. The gap is that it gives no guidance on when to pick this tool over the sibling graphql-query/get-schema, which is the main selection decision an agent faces.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full content of an Nhost documentation page. Use this after searching to get the complete documentation for a specific page.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The documentation page path (e.g., /products/auth/overview or products/auth/overview) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the 'complete documentation' scope, with no notes on caching, freshness, or error behavior when a path is invalid.
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?
Two short sentences with the purpose front-loaded and the usage cue second; every clause earns its place with no redundancy.
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 single-parameter read-only documentation lookup with full annotation coverage and no output schema, the description is nearly complete. Only minor edge-case guidance (invalid paths, path formatting) is absent.
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 100% and the single 'path' parameter is documented with an example in the schema, so the baseline is 3. The description adds no additional meaning about path format, leading-slash handling, or valid page identifiers beyond what the schema provides.
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 states a specific verb and resource — 'Read the full content of an Nhost documentation page' — which is distinct from sibling retrieval tools like search or list. It scopes the output as 'full content' versus search's partial results, though it does not name the sibling tool explicitly.
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?
It gives a clear sequencing instruction: 'Use this after searching to get the complete documentation for a specific page,' telling the agent when the tool applies relative to search. It stops short of stating exclusions or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Nhost's official documentation. Use this tool to look for information about Nhost's features, APIs, guides, etc. Returns relevant documentation pages with highlighted snippets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 10) | |
| query | Yes | The search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds the return shape (relevant pages with highlighted snippets), which is useful context, but says nothing about result limits behavior or ranking.
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?
Three short sentences, front-loaded with the core action before usage and return details. The middle sentence's enumeration of content types is slightly filler but not wasteful enough to penalize heavily.
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?
No output schema exists, and the description compensates by describing the return (relevant documentation pages with highlighted snippets). Combined with full schema coverage and rich annotations, an agent has enough to call it correctly; only filtering/ranking behavior is unstated.
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 100%, so both query and limit are already documented in the schema, including the default. The description adds no syntax, format, or query-construction guidance beyond that, so the baseline of 3 applies.
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?
States a specific verb and resource: searching Nhost's official documentation, and names the content domain (features, APIs, guides). It does not explicitly distinguish itself from the sibling read_page, which also touches documentation content, so it falls short of a 5.
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?
"Use this tool to look for information about Nhost's features, APIs, guides" implies when to reach for it, but gives no exclusions or alternatives despite a closely related sibling (read_page) that an agent could confuse it with. Usage is implied rather than directed.
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.
v1.52.0get-schemagraphql-querylistmanage-graphqlread_pagesearchScored across 6 tools
Three GraphQL-related tools (get-schema, graphql-query, manage-graphql) could be confused at first glance, but descriptions clarify distinct roles: schema retrieval, data querying, and management endpoint access. The docs trio (list/search/read_page) overlaps slightly since list and search both help discover pages, though read_page is clearly distinct.
Names mix conventions: get-schema, graphql-query, manage-graphql use kebab-case verb-noun, read_page uses snake_case, and list/search are bare verbs with no noun. Still readable and inferable, but not a predictable single pattern.
Six tools is well-scoped for a GraphQL backend with documentation: schema, query, management, and doc discovery/retrieval each earn their place. No redundant or filler tools.
Covers the core domain well—schema introspection, data query/mutation, metadata and migration management, plus full docs access (list/search/read). Minor gaps around project-level or auth configuration operations, but agents can work around them.
MCP server for interacting with the Supabase platform
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
The Instant MCP server is a wrapper around the Instant Platform SDK that enables creating, managing, and updating InstantDB applications directly within an editor. It provides tools for fetching rules files for LLMs, retrieving and pushing app schemas, managing permission rules, and executing database queries. Key capabilities include schema management (get-schema, push-schema), permission management (get-perms, push-perms), query execution, and listing recent query history.
