Skip to main content
Glama
enesjakozh
christian561

Gel Database MCP Server

by christian561
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

겔 데이터베이스 MCP 서버

EdgeQL 쿼리를 사용하여 Gel 데이터베이스 작업을 간소화하도록 설계된 TypeScript 기반 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 프로젝트는 LLM 에이전트(Cursor Agent, Claude Code 등)를 위한 도구를 제공하여 스키마 학습, 데이터베이스 쿼리 작성, 검증 및 실행을 자동화합니다. 자연어를 통해 Gel 데이터베이스와 쉽게 상호 작용할 수 있습니다. Vibe 코더 여러분, 환호하세요!

참고: LLM은 더 유연한 쿼리를 작성할 수 있으므로 쿼리 생성은 포함되지 않습니다. Claude-3.7-sonnet-thinking을 사용하여 커서 에이전트로 테스트했으며, 관련 웹페이지를 연결하여 Gel 문서를 제공한 후 좋은 결과를 얻었습니다.

프로젝트 아키텍처 다이어그램

빠른 시작 가이드

지엑스피1

커서에서 MCP 서버 연결

  1. 오른쪽 상단의 기어 아이콘 > MCP > +새 서버 추가를 클릭하세요.

  2. 원하는 대로 이름을 지어주세요

  3. 유형 선택: 명령

  4. 다음을 입력하세요: node your/full/path/to/build/index.js

커서 MCP 설정 스크린샷

참고: 이 서버는 주로 Cursor 에이전트로 테스트되었지만, Model Context Protocol을 지원하는 다른 에이전트 및 LLM에서도 작동할 것입니다. 다른 에이전트로 테스트하시는 경우, 결과를 공유해 주세요!

Related MCP server: MCP Docs RAG Server

사용 가능한 도구

Gel Database MCP 서버는 다음과 같은 도구를 제공합니다.

설명 스키마

이를 통해 LLM 에이전트는 코드를 직접 검사하지 않고도 데이터베이스 구조를 파악하고 이해할 수 있습니다. 에이전트는 사용 가능한 엔터티 유형, 속성, 관계 및 제약 조건을 파악하여 더욱 정확한 쿼리를 생성할 수 있습니다.

사용 시기: 에이전트가 쿼리를 실행하기 전에 데이터베이스 엔터티의 구조를 이해해야 하는 경우입니다. 영상

유효성 검사 쿼리

이를 통해 LLM 에이전트는 원시 EdgeQL 쿼리 구문을 실행하지 않고도 확인할 수 있으므로, 생성된 쿼리를 데이터베이스에 실행하기 전에 안전하게 검증할 수 있습니다.

사용 시기: 실행 부작용의 위험 없이 구문을 확인하기 위해 쿼리를 개발하는 동안. 영상

실행-edgeql

이를 통해 LLM 에이전트는 원시 EdgeQL 쿼리를 실행하고, 데이터를 검색하고, 사용자의 지시에 따라 작업을 수행하여 데이터베이스와 직접 상호 작용할 수 있습니다. LLM은 EdgeQL 쿼리를 생성하고 이를 자율적으로 실행할 수 있습니다.

예:

SELECT Product { name, price } FILTER .price > 100;

영상

검색-젤-문서

이 도구를 사용하면 LLM 에이전트가 Gel 문서를 검색하여 EdgeQL 구문, 기능 또는 예시에 대한 관련 정보를 찾을 수 있습니다. 에이전트가 Gel 데이터베이스 개념을 더 잘 이해할 수 있도록 맥락과 함께 포괄적인 결과를 제공합니다.

사용 시기: 에이전트가 특정 Gel/EdgeQL 기능에 대해 알아야 할 때, 구문을 이해해야 할 때, 데이터베이스 작업 구현에 대한 예를 찾아야 할 때.

예:

search_term: "for loop"
context_lines: 10  # Optional: Number of context lines to show (default: 5)
match_all_terms: true  # Optional: Require all terms to match (default: false)

문서화 하이브리드 접근 방식에 대한 참고 사항: 최적의 결과를 얻으려면 다음 두 가지를 모두 권장합니다.

  1. 프로젝트 루트에 gel_llm.txt 파일을 포함합니다(직접 파일 액세스를 위해)

  2. 타겟 쿼리에 대한 search-gel-docs 도구 사용

이러한 하이브리드 접근 방식은 LLM 에이전트에게 특정 용어를 검색하는 동시에 필요한 경우 더 광범위한 맥락에서 전체 문서에 접근할 수 있는 유연성을 제공합니다.

실행-타입스크립트

execute-edgeql과 비슷하지만 쿼리 빌더 구문으로 만든 Typescript Gel 쿼리를 테스트하고 실행하는 데 사용할 수 있습니다.

도구에 지침이 포함되어 있지만, 상담원에게 어떤 지침이 있는지 물어보는 것이 좋습니다. 그래야 상황에 맞게 지침이 표시됩니다. 이렇게 하면 지침이 누락되는 것을 방지할 수 있습니다.

참고: 일반적인 JavaScript 구문 오류로 인해 서버가 중단될 수 있으므로 연결이 닫힌 것으로 나타나면 커서 MCP 설정에서 중단된 서버를 새로 고치거나 서버를 다시 시작해야 합니다.

LLM에 다음과 같은 모범 사례를 알려주세요.

  • console.log와 함께 await gelClient.query() 사용하여 결과를 표시합니다.

  • THEN과 함께 ORDER BY를 사용하고 쉼표는 사용하지 마세요(예: ORDER BY .field1 THEN .field2)

  • 코드를 단순하게 유지하고 단일 작업에 집중하세요.

예:

console.log(await gelClient.query(`
  SELECT Product { 
    name, 
    price 
  } 
  FILTER .price > 100 
  ORDER BY .price DESC 
  LIMIT 5;
`));

사용 시기: 프로그래밍 논리가 필요한 복잡한 쿼리나 JavaScript로 쿼리 결과를 처리해야 하는 경우.

영상

자세히 알아보기

모델 컨텍스트 프로토콜에 대한 자세한 내용은 modelcontextprotocol.io/quickstart를 방문하세요.

Available Tools

2 tools
get-alertsC

Get weather alerts for a state

ParametersJSON Schema
NameRequiredDescriptionDefault
stateYesTwo-letter state code (e.g. CA, NY)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe traits like rate limits, authentication needs, error handling, or response format. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns complex alert data. It doesn't explain what the alerts include, how they're formatted, or any limitations, leaving the agent with insufficient context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description doesn't add any parameter-specific information beyond what's in the input schema, which has 100% coverage and fully documents the 'state' parameter. This meets the baseline score of 3, as the schema adequately handles parameter semantics without needing extra description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('weather alerts for a state'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from its sibling tool 'get-forecast', which likely provides different weather data, so it doesn't reach the highest score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus its sibling 'get-forecast' or any alternatives. It lacks context about usage scenarios, exclusions, or prerequisites, offering only a basic statement of function.

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

get-forecastC

Get weather forecast for a location

ParametersJSON Schema
NameRequiredDescriptionDefault
latitudeYesLatitude of the location
longitudeYesLongitude of the location

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe any behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, or what the response format might be. This is inadequate for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that efficiently conveys the core purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there are no annotations and no output schema, the description is incomplete. It doesn't provide enough context about behavioral aspects, response format, or how this tool differs from its sibling. For a tool with this level of complexity and lack of structured data, the description should do more to compensate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with both parameters (latitude and longitude) well-documented in the schema. The description doesn't add any meaningful parameter semantics beyond what's already in the schema, so it meets the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('weather forecast for a location'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'get-alerts', which likely provides different weather-related information, so it doesn't achieve the highest score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling 'get-alerts' or explain the difference between getting a forecast versus alerts, leaving the agent without context for tool selection.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observedget-alerts
    • First observedget-forecast
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one retrieves weather alerts for states, while the other retrieves forecasts for locations. There is no overlap in functionality, and an agent can easily differentiate between them based on their descriptions.

Naming Consistency5/5

Both tools follow a consistent verb_noun naming pattern (get-alerts and get-forecast). The hyphenated style is uniform across all tools, making them predictable and easy to understand.

Tool Count2/5

With only two tools, the server feels thin for a weather database domain. It lacks essential operations like updating data, searching historical records, or managing locations, which limits its utility for comprehensive weather-related tasks.

Completeness2/5

The tool surface is severely incomplete for a database server. It only provides read operations (get-alerts and get-forecast) with no create, update, delete, or search capabilities. This creates significant gaps that will hinder agents from performing full database workflows.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • CouchDB MCP Server

    robertoamoreno
    F
    license
    A
    quality
    D
    maintenance
    A TypeScript-based MCP server that enables AI assistants to interact with CouchDB databases through a simple interface, providing tools for creating, reading, and querying databases and documents.
    5
    5
    -

  • MCP Docs RAG Server

    kazuph
    F
    license
    A
    quality
    D
    maintenance
    A TypeScript MCP server that allows querying documents using LLMs with context from locally stored repositories and text files through a RAG (Retrieval-Augmented Generation) system.
    4
    17
    -

  • MCP-Typescribe

    yWorks
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that enables LLMs to understand and work with TypeScript APIs they haven't been trained on by providing structured access to TypeScript type definitions and documentation.
    14 npm
    46
    MIT

Appeared in Searches