Execute read-only GraphQL queries on a Hasura endpoint, providing a query string and optional variables to retrieve data efficiently.
363,317 tools. Last updated 2026-08-01 21:54
"Hasura" matching MCP tools:
- Retrieve and organize data tables managed by Hasura, filtered by schema, to simplify database exploration and schema discovery.
- Verify the reachability of a Hasura GraphQL endpoint by testing its health status using a specific HTTP URL to ensure operational reliability.
- Retrieve a sample of rows from a specified table to preview data, with an optional row limit, for efficient schema exploration and query validation.
- Examine table structure with column types and descriptions using a Hasura GraphQL MCP Server. Input table name and optional schema to retrieve details.
- Execute GraphQL mutations to insert, update, or delete data on Hasura GraphQL endpoints. Define the mutation string and optional variables for precise data manipulation.
Matching MCP Servers
- Alicense-qualityDmaintenanceEnables read-only interaction with Hasura GraphQL APIs, including table exploration, data preview, and schema introspection.Last updated74MIT
- FlicenseAqualityDmaintenanceA Model Context Protocol server that enables AI agents to dynamically interact with Hasura GraphQL endpoints through natural language, supporting schema discovery, data querying/manipulation, and aggregations.Last updated923
- Retrieve available top-level query, mutation, or subscription fields for a Hasura GraphQL endpoint to enable schema discovery and dynamic interaction with the API.
- Retrieve comprehensive details about a specified GraphQL type, including its structure and usage. Ideal for understanding and integrating GraphQL schemas in Hasura-based applications.
- Perform data aggregations (count, sum, avg, min, max) on specified tables using a Hasura GraphQL filter. Supported by the Advanced Hasura GraphQL MCP Server for efficient data analysis.
- Query records from Well's database. ⚠️ WORKFLOW: 1. To SHOW the user a table of a record type, omit `fields` — you get the root's display view in the Well web app's column order, trimmed on the widest roots to the columns that fit a chat-width table. Prefer this whenever the user asks to see/list/browse records rather than to answer a question about one specific attribute. Ask for `fields` explicitly when you need a column it omits. 2. To answer a targeted question, call well_get_schema(root) FIRST to discover available fields, then select ONLY the fields you need (5-15 typically). ROOTS (read-only — all 32): companies, people, connectors, invoices, documents, transactions, accounts, payment_means, workspace_connectors, memberships, cards, checks, ledger_accounts, journals, journal_entries, tax_rates, exchange_rates, invoice_transactions, categories, account_balances, tasks, workspaces, invoice_payment_means, chat_conversations, blueprint_runs, workspace_connector_sync_logs, media, emails, phones, web_links, locations, invoice_items (The accounting graph — ledger_accounts, journals, journal_entries — and balances/rates are read-only projections owned by the sync/posting pipelines; query them for financial context, you cannot create/update them here. Sub-resources like emails/phones/locations are usually richer when read via their parent company/person.) CONNECTED TOOLS: do NOT use this tool to show the user what they have connected — call well_list_connectors instead. It owns that job: connection status, and an install link for anything not connected yet. Query root "workspace_connectors" here only for genuine RECORD-level needs — reading sync timestamps, filtering connections, joining them with other roots. ("connectors" is the installable catalog; "workspace_connector_sync_logs" is per-sync history.) Well already syncs the providers' data into the roots above — invoices, transactions, accounts, the accounting graph. ALWAYS read it from here. well_invoke_connector_tool and a provider's own tools are for an ACTION the user explicitly asked to take on that provider (e.g. "create this record in Attio"), never a way to fetch data Well already holds. EXAMPLE - Get all invoices for dashboard: well_query_records({ root: "invoices", fields: [ ["invoices", "invoice_number"], ["invoices", "grand_total"], ["invoices", "issue_date"], ["invoices", "issuer", "name"], ["invoices", "receiver", "name"] ], limit: 50 }) ⚠️ RULES: - Omitting fields (default view) or selecting specific fields both beat allFields - Field paths from schema: "invoices.issuer.name" → ["invoices", "issuer", "name"] - Default 50 records per request, max 500. Use cursor pagination for more. PAGINATION (cursor-based): - First call: omit cursor. Response includes nextCursor. - Next page: pass the returned nextCursor as cursor. - Last page: nextCursor is null. Example: Page 1: well_query_records({ root: "invoices", fields: [...], limit: 50 }) → { rows: [...], nextCursor: "eyJpZCI6MTAwfQ==" } Page 2: well_query_records({ root: "invoices", fields: [...], limit: 50, cursor: "eyJpZCI6MTAwfQ==" }) → { rows: [...], nextCursor: null } // last page FILTERING (whereClause): - Uses Hasura-style operators on field names. - Safe operators (work on ALL field types): _eq, _neq, _in, _nin, _is_null - Numeric/date only: _gt, _gte, _lt, _lte - Text only: _like, _ilike - When unsure of a field's type, prefer _eq or _in (they always work). - Combine with _and, _or, _not - For relationship fields, use nested syntax: { "issuer": { "name": { "_ilike": "%acme%" } } } Examples: { "status": { "_eq": "unpaid" } } { "grand_total": { "_gt": 1000 } } { "local_currency": { "_eq": "EUR" } } { "_and": [{ "status": { "_eq": "unpaid" } }, { "grand_total": { "_gte": 500 } }] } { "issuer": { "name": { "_ilike": "%acme%" } } } SORTING (orderBy): - Sort by any field: { field: "grand_total", direction: "desc" } - Default sort is by primary key ascending. Returns { rows, totalCount, nextCursor, success }.Connector