Supports writing data using InfluxDB Line Protocol format to GigAPI's timeseries database, enabling seamless data ingestion from InfluxDB-compatible sources.
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., "@GigAPI MCP Server show me the schema for the temperature_data table in mydb"
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.
An MCP server for GigAPI Timeseries Lake that provides seamless integration with Claude Desktop and other MCP-compatible clients.
run_select_query
Execute SQL queries on your GigAPI cluster.
Input: sql (string): The SQL query to execute, database (string): The database to execute against.
All queries are executed safely through GigAPI's HTTP API with NDJSON format.
list_databases
List all databases on your GigAPI cluster.
Input: database (string): The database to use for the SHOW DATABASES query (defaults to "mydb").
list_tables
List all tables in a database.
Input: database (string): The name of the database.
get_table_schema
Get schema information for a specific table.
Input: database (string): The name of the database, table (string): The name of the table.
write_data
Write data using InfluxDB Line Protocol format.
Input: database (string): The database to write to, data (string): Data in InfluxDB Line Protocol format.
health_check
Check the health status of the GigAPI server.
ping
Ping the GigAPI server to check connectivity.
Related MCP server: A2A MCP Server
# The package will be available on PyPI after the first release
# Users can install it directly with uv
uv run --with mcp-gigapi --python 3.11 mcp-gigapi --help# Clone the repository
git clone https://github.com/gigapi/mcp-gigapi.git
cd mcp-gigapi
# Install dependencies
uv syncOpen the Claude Desktop configuration file located at:
On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%/Claude/claude_desktop_config.json
Add the following configuration:
{
"mcpServers": {
"mcp-gigapi": {
"command": "uv",
"args": [
"run",
"--with",
"mcp-gigapi",
"--python",
"3.13",
"mcp-gigapi"
],
"env": {
"GIGAPI_HOST": "gigapi.fly.dev",
"GIGAPI_PORT": "443",
"GIGAPI_TIMEOUT": "30",
"GIGAPI_VERIFY_SSL": "true",
"GIGAPI_DEFAULT_DATABASE": "mydb"
}
}
}
}{
"mcpServers": {
"mcp-gigapi": {
"command": "uv",
"args": [
"run",
"--with",
"mcp-gigapi",
"--python",
"3.13",
"mcp-gigapi"
],
"env": {
"GIGAPI_HOST": "localhost",
"GIGAPI_PORT": "7971",
"GIGAPI_TIMEOUT": "30",
"GIGAPI_VERIFY_SSL": "false",
"GIGAPI_DEFAULT_DATABASE": "mydb"
}
}
}
}{
"mcpServers": {
"mcp-gigapi": {
"command": "uv",
"args": [
"run",
"--with",
"mcp-gigapi",
"--python",
"3.13",
"mcp-gigapi"
],
"env": {
"GIGAPI_HOST": "your-gigapi-server",
"GIGAPI_PORT": "7971",
"GIGAPI_USERNAME": "your_username",
"GIGAPI_PASSWORD": "your_password",
"GIGAPI_TIMEOUT": "30",
"GIGAPI_VERIFY_SSL": "true",
"GIGAPI_DEFAULT_DATABASE": "your_database"
}
}
}
}Important: Replace the uv command with the absolute path to your uv executable:
which uv # Find the pathRestart Claude Desktop to apply the changes.
This MCP server is designed to work with GigAPI's HTTP API endpoints:
POST /query?db={database}&format=ndjson - Execute SQL queries with NDJSON response format
All queries return NDJSON (Newline Delimited JSON) format for efficient streaming
POST /write?db={database} - Write data using InfluxDB Line Protocol
GET /health - Health check
GET /ping - Simple ping
Use InfluxDB Line Protocol format:
curl -X POST "http://localhost:7971/write?db=mydb" --data-binary @/dev/stdin << EOF
weather,location=us-midwest,season=summer temperature=82
weather,location=us-east,season=summer temperature=80
weather,location=us-west,season=summer temperature=99
EOFExecute SQL queries via JSON POST with NDJSON format:
curl -X POST "http://localhost:7971/query?db=mydb&format=ndjson" \
-H "Content-Type: application/json" \
-d '{"query": "SELECT time, temperature FROM weather WHERE time >= epoch_ns('\''2025-04-24T00:00:00'\''::TIMESTAMP)"}'# Show databases
curl -X POST "http://localhost:7971/query?db=mydb&format=ndjson" \
-H "Content-Type: application/json" \
-d '{"query": "SHOW DATABASES"}'
# Show tables
curl -X POST "http://localhost:7971/query?db=mydb&format=ndjson" \
-H "Content-Type: application/json" \
-d '{"query": "SHOW TABLES"}'
# Count records
curl -X POST "http://localhost:7971/query?db=mydb&format=ndjson" \
-H "Content-Type: application/json" \
-d '{"query": "SELECT count(*), avg(temperature) FROM weather"}'GIGAPI_HOST: The hostname of your GigAPI server
GIGAPI_PORT: The port number of your GigAPI server (default: 7971)
GIGAPI_USERNAME or GIGAPI_USER: The username for authentication (if required)
GIGAPI_PASSWORD or GIGAPI_PASS: The password for authentication (if required)
GIGAPI_TIMEOUT: Request timeout in seconds (default: 30)
GIGAPI_VERIFY_SSL: Enable/disable SSL certificate verification (default: true)
GIGAPI_DEFAULT_DATABASE: Default database to use for queries (default: mydb)
GIGAPI_MCP_SERVER_TRANSPORT: Sets the transport method for the MCP server (default: stdio)
GIGAPI_ENABLED: Enable/disable GigAPI functionality (default: true)
# Required variables
GIGAPI_HOST=localhost
GIGAPI_PORT=7971
# Optional: Override defaults for local development
GIGAPI_VERIFY_SSL=false
GIGAPI_TIMEOUT=60
GIGAPI_DEFAULT_DATABASE=mydb# Required variables
GIGAPI_HOST=your-gigapi-server
GIGAPI_PORT=7971
GIGAPI_USERNAME=your_username
GIGAPI_PASSWORD=your_password
# Optional: Production settings
GIGAPI_VERIFY_SSL=true
GIGAPI_TIMEOUT=30
GIGAPI_DEFAULT_DATABASE=your_databaseGIGAPI_HOST=gigapi.fly.dev
GIGAPI_PORT=443
GIGAPI_VERIFY_SSL=true
GIGAPI_DEFAULT_DATABASE=mydbGigAPI uses Hive partitioning with the structure:
/data
/mydb
/weather
/date=2025-04-10
/hour=14
*.parquet
metadata.jsonInstall dependencies:
uv sync --all-extras --dev
source .venv/bin/activateCreate a .env file in the root of the repository:
GIGAPI_HOST=localhost
GIGAPI_PORT=7971
GIGAPI_USERNAME=your_username
GIGAPI_PASSWORD=your_password
GIGAPI_TIMEOUT=30
GIGAPI_VERIFY_SSL=false
GIGAPI_DEFAULT_DATABASE=mydbFor testing with the MCP Inspector:
fastmcp dev mcp_gigapi/mcp_server.py# Run all tests
uv run pytest -v
# Run only unit tests
uv run pytest -v -m "not integration"
# Run only integration tests
uv run pytest -v -m "integration"
# Run linting
uv run ruff check .
# Test with public demo
python test_demo.pyThe repository includes a test script that validates the MCP server against the public GigAPI demo:
python test_demo.pyThis will test:
✅ Health check and connectivity
✅ Database listing (SHOW DATABASES)
✅ Table listing (SHOW TABLES)
✅ Data queries (SELECT count(*) FROM table)
✅ Sample data retrieval
This package is automatically published to PyPI on each GitHub release. The publishing process is handled by GitHub Actions workflows:
CI Workflow (.github/workflows/ci.yml): Runs tests on pull requests and pushes to main
Publish Workflow (.github/workflows/publish.yml): Publishes to PyPI when a release is created
Once published, users can install the package directly from PyPI:
# Install and run the MCP server
uv run --with mcp-gigapi --python 3.11 mcp-gigapiTo publish a new version:
Update the version in pyproject.toml
Create a GitHub release
The workflow will automatically publish to PyPI
See RELEASING.md for detailed release instructions.
Connection refused: Check that GigAPI is running and the host/port are correct
Authentication failed: Verify username/password are correct
SSL certificate errors: Set GIGAPI_VERIFY_SSL=false for self-signed certificates
No databases found: Ensure you're using the correct default database (usually "mydb")
Enable debug logging by setting the log level:
import logging
logging.basicConfig(level=logging.DEBUG)Apache-2.0 license
Fork the repository
Create a feature branch
Make your changes
Add tests
Submit a pull request
Issues: GitHub Issues
Documentation: GigAPI Documentation
Get schema information for a specific table.
| Name | Required | Description | Default |
|---|---|---|---|
| input_data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fails to disclose behavioral traits such as input format, error handling for missing tables, or authentication requirements. It only implies a read operation.
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, but it lacks structure. While concise, it omits necessary detail about parameters and behavior, making it minimally adequate.
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 lack of output schema and parameter descriptions, the description is incomplete. It does not explain return values or input specifics, leaving agents without critical information.
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 input schema has 0% description coverage for its single parameter 'input_data'. The description only implies it represents a table identifier but does not specify format or constraints, leaving ambiguity.
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 'Get schema information for a specific table' clearly states a specific verb and resource, distinguishing it from sibling tools like list_tables which list tables rather than retrieving schema.
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 versus alternatives (e.g., list_tables, run_select_query). The description does not specify prerequisites or exclude scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the health status of the GigAPI server.
| Name | Required | Description | Default |
|---|---|---|---|
| _ | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose whether the tool is read-only, has side effects, or what the response includes. For a health check, it is likely safe, but this is 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?
The description is a single short sentence, but it omits crucial details. Conciseness is not beneficial when it leads to incompleteness.
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 lack of annotations, output schema, and a cryptic required parameter, the description provides insufficient information for an agent to use the tool correctly or interpret 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?
The single required parameter '_' is not described in the schema or the description. With 0% schema description coverage, the description fails to explain its purpose or necessity.
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 checks the health status of the GigAPI server, using a specific verb and resource. However, it does not distinguish from the sibling tool 'ping', which likely has a similar purpose.
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 is provided on when to use this tool versus alternatives like 'ping'. The description implies usage for health checking, but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all databases on your GigAPI cluster.
| Name | Required | Description | Default |
|---|---|---|---|
| input_data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description truthfully indicates a read operation but lacks details on authentication, limits, or side effects. For a simple list tool, this is adequate but not thorough.
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 sentence, front-loaded, no unnecessary words.
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?
Despite low complexity, the description fails to address the required input parameter, leaving ambiguity about what data to provide.
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%, and the description does not explain the single required 'input_data' parameter or its purpose, which is critical for correct invocation.
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 action ('List') and resource ('all databases on your GigAPI cluster'), distinguishing it from sibling tools like list_tables.
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 or not use this tool, no mention of alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tables in a database.
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the basic operation and does not mention potential side effects, permissions, or performance implications, which is insufficient for a tool with no annotations.
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, clear sentence of 5 words with no redundancy. It is appropriately sized for the tool's simplicity and front-loads the core purpose effectively.
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?
The description is minimally adequate for a simple tool with one parameter and no output schema. However, it lacks details about return format, error behavior, and relationship to siblings, leaving some gaps in 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?
Schema description coverage is 0%, and the description adds no meaning to the 'database' parameter. It does not specify valid values, format, or behavior if the database does not exist, failing to compensate for the lack of schema descriptions.
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 'List all tables in a database' clearly specifies the verb (list), resource (tables), and context (in a database). It effectively distinguishes from siblings like list_databases and get_table_schema, making the tool's purpose unambiguous.
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 is provided on when to use this tool versus alternatives. For example, it does not explain when to use list_tables vs. list_databases or get_table_schema, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ping the GigAPI server to check connectivity.
| Name | Required | Description | Default |
|---|---|---|---|
| _ | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the action without disclosing what the response contains, potential side effects, or any behavioral traits. Extremely minimal.
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, which is concise, but it is under-specified for a tool with an undocumented required parameter. Conciseness should not come at the expense of completeness.
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 ping tool with one required parameter and no output schema, a minimal description might suffice, but the lack of explanation for the parameter and comparison with sibling tools makes it incomplete.
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 input schema has one required parameter '_' with 0% description coverage. The description does not explain this parameter at all, leaving the agent to guess its purpose.
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 action (ping) and the resource (GigAPI server) with a specific purpose (check connectivity). However, it does not differentiate from the sibling tool 'health_check', which likely serves a similar purpose.
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 provides no guidance on when to use this tool versus alternatives like 'health_check'. No context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute SQL queries on your GigAPI cluster. All queries are executed safely.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| database | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must reveal behavior. 'All queries are executed safely' is vague; it doesn't clarify read-only nature, error handling, or execution limits.
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, concise but not optimally structured. It could be expanded meaningfully without sacrificing brevity.
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 or output schema, the description lacks completeness. It omits return values, execution constraints, and example usage.
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% and the description adds no meaning beyond the parameter names (sql, database). No hints on format 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 'Execute SQL queries on your GigAPI cluster', providing a specific verb and resource. However, the name 'run_select_query' contrasts with 'SQL queries' which could include writes, causing slight ambiguity.
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 is given on when to use this tool versus siblings like write_data or get_table_schema. The description lacks context for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write data using InfluxDB Line Protocol format.
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | ||
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits but only mentions the format; it omits details about mutation, idempotency, auth requirements, or error behavior.
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 that is front-loaded and contains no superfluous words, efficiently communicating the core action and format.
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 mutating tool with no output schema and no annotations, the description lacks details on return values, error handling, and write semantics, making it incomplete.
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 adds meaning by specifying the Line Protocol format for the 'data' parameter, but the 'database' parameter is left unexplained.
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 writes data using InfluxDB Line Protocol format, which distinguishes it from read-only sibling tools like list_databases and run_select_query.
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 is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions.
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.
get_table_schemahealth_checklist_databaseslist_tablespingrun_select_querywrite_dataMost tools target distinct actions (schema, listing, query, write), but health_check and ping both relate to server connectivity, causing slight potential confusion despite different phrasing.
Snake_case is used consistently, but the verb_noun pattern is not uniform: 'health_check' is a compound noun and 'ping' is a bare verb, while others use verb_noun. This is a minor inconsistency.
Seven tools is well-scoped for a database API server—covering schema inspection, listing, querying, writing, and health checks—without being excessive or insufficient.
The set covers basic CRUD (read and write) and schema discovery, but lacks DDL tools (create/alter/drop tables or databases) and data deletion, leaving notable gaps for full life-cycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server providing attendance data queries via the CloudTime API.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
MCP server for progressive tool usage at any scale (see https://klavis.ai)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gigapi/gigapi-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
