Skip to main content
Glama
sirbramantyo

Antigravity Voice MCP

by sirbramantyo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Antigravity Voice MCP

Local MCP (Model Context Protocol) server untuk menghubungkan Google Antigravity IDE dengan Windows Text-to-Speech.

Project ini menyediakan tool suara yang bisa dipanggil melalui MCP, sehingga Antigravity dapat membacakan teks, ringkasan, atau status pekerjaan melalui speaker Windows.

Status

Version: 1.1.0

Fitur saat ini:

  • speak — membacakan teks menggunakan Windows Text-to-Speech.

  • list_voices — menampilkan voice Windows yang tersedia.

  • Dukungan pengaturan:

    • voice

    • rate

    • volume

  • MCP transport melalui stdio.

  • Windows PowerShell + System.Speech.

  • Sudah diuji pada Windows 11 dengan Node.js 24.

Related MCP server: mac-say-mcp

Requirements

Pastikan device memiliki:

  • Windows 10 atau Windows 11

  • Node.js

  • npm

  • Google Antigravity IDE

  • Windows Text-to-Speech voice yang aktif

Cek Node.js dan npm:

node -v
npm -v

Installation

Clone repository:

git clone https://github.com/sirbramantyo/antigravity-voice-mcp.git

Masuk ke folder project:

cd antigravity-voice-mcp

Install dependency:

npm install

Project Structure

antigravity-voice-mcp
├── src
│   ├── index.js
│   ├── test-client.js
│   └── test-tts.js
├── .gitignore
├── package.json
├── package-lock.json
└── README.md

Test Windows Text-to-Speech

Untuk memastikan Node.js dapat menjalankan Windows TTS:

node src/test-tts.js

Jika berhasil, speaker akan membacakan kalimat test.

Test MCP Server

Jalankan:

node src/test-client.js

Expected result:

Available MCP tools:
- speak
- list_voices

Tool list_voices akan menampilkan voice Windows yang terpasang, lalu tool speak akan menjalankan Text-to-Speech.

Contoh voice yang pernah terdeteksi:

Microsoft Hazel Desktop
Microsoft Zira Desktop

Antigravity MCP Configuration

Antigravity membaca custom MCP server melalui file:

~/.gemini/config/mcp_config.json

Pada Windows, lokasi tersebut biasanya berada di folder user.

Tambahkan konfigurasi berikut ke object mcpServers:

{
  "mcpServers": {
    "antigravity-voice": {
      "command": "C:\\Program Files\\nodejs\\node.exe",
      "args": [
        "D:\\PATH\\TO\\antigravity-voice-mcp\\src\\index.js"
      ],
      "cwd": "D:\\PATH\\TO\\antigravity-voice-mcp"
    }
  }
}

Ganti:

D:\PATH\TO\antigravity-voice-mcp

dengan lokasi repository pada device Anda.

Contoh:

E:\Documents\Web_Development\Tools\antigravity-voice-mcp

Penting: absolute path berbeda pada setiap device. Jangan menyalin path dari laptop lain tanpa menyesuaikannya.

Node.js Path

Untuk mengetahui path Node.js pada Windows:

where.exe node

Contoh hasil:

C:\Program Files\nodejs\node.exe

Gunakan path tersebut pada field command di mcp_config.json.

Enable MCP di Antigravity

Di Antigravity IDE:

  1. Buka Agent panel.

  2. Buka menu MCP Servers.

  3. Pilih Manage MCP Servers.

  4. Pastikan antigravity-voice muncul.

  5. Enable atau refresh server setelah mengubah index.js atau konfigurasi MCP.

Tool: speak

Tool speak menerima parameter:

text
voice
rate
volume

Default configuration:

voice  = Microsoft Zira Desktop
rate   = 2
volume = 100

Range:

rate   = -10 sampai 10
volume = 0 sampai 100

Contoh pemanggilan:

{
  text: "Build completed successfully.",
  voice: "Microsoft Zira Desktop",
  rate: 2,
  volume: 100
}

Jika voice, rate, dan volume tidak dikirim, server menggunakan nilai default.

Tool: list_voices

Tool ini membaca voice yang tersedia melalui Windows System.Speech.

Gunakan tool ini sebelum memilih voice custom pada device baru, karena daftar voice dapat berbeda antar komputer.

Important Notes

Jangan commit folder berikut:

node_modules/

Repository sudah menggunakan .gitignore.

File global Antigravity:

~/.gemini/config/mcp_config.json

juga tidak perlu dimasukkan ke repository karena berisi absolute path yang spesifik untuk masing-masing device.

Updating the Project

Setelah melakukan perubahan source code:

git add .
git commit -m "Describe your change"
git push

Pada device lain, update repository dengan:

git pull
npm install

npm install diperlukan jika dependency pada package.json berubah.

Troubleshooting

MCP server tidak muncul di Antigravity

Periksa:

  • path Node.js pada command

  • path src/index.js

  • nilai cwd

  • JSON syntax pada mcp_config.json

Setelah memperbaiki konfigurasi, refresh MCP server.

MCP terhubung tetapi suara tidak terdengar

Test langsung:

node src/test-tts.js

Jika direct TTS gagal, masalah berada pada Windows TTS atau PowerShell, bukan MCP.

Jika direct TTS berhasil tetapi MCP gagal, jalankan:

node src/test-client.js

untuk mengisolasi masalah antara MCP client dan server.

Voice tidak ditemukan

Jalankan list_voices atau test client untuk melihat nama voice yang benar-benar tersedia pada device tersebut.

Nama voice harus sama persis dengan nama yang dilaporkan Windows.

Recommended Workflow

Gunakan voice terutama untuk notifikasi singkat seperti:

Build completed successfully.
Tests passed.
Three tests failed.
Deployment finished.

Membacakan seluruh response coding yang panjang biasanya kurang efisien.

License

Private/internal utility project unless changed by repository owner.

Available Tools

2 tools
list_voicesList VoicesA

List installed Windows Text-to-Speech voices.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and 'List installed' reasonably implies a non-destructive, side-effect-free read. However, it says nothing explicit about read-only behavior, cost, or whether the call has any effect on system state, leaving the safety profile to inference.

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?

A single front-loaded sentence with no wasted words. Nothing is repeated from the title beyond the necessary resource name.

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

Completeness3/5

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

There is no output schema, so the description should ideally say what is returned (e.g., voice names/identifiers usable with 'speak'), but it does not. For a trivial zero-param list tool this is a minor but real gap.

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

Parameters4/5

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

The tool takes zero parameters, so there is nothing for the description to clarify; the baseline for a parameterless tool applies. No parameter semantics are needed or missing.

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 states a specific verb (List) and resource (installed Windows Text-to-Speech voices), scoping it to Windows TTS. It is clearly distinct from the only sibling 'speak', which performs synthesis rather than enumeration, though it never explicitly names or contrasts with that sibling.

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

Usage Guidelines3/5

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

Usage is only implied: an agent would infer this is the discovery step before calling 'speak', but the description never states when to call it or how it relates to the sibling. No exclusions or prerequisites are given.

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

speakSpeakC

Speak text aloud using Windows Text-to-Speech.

ParametersJSON Schema
NameRequiredDescriptionDefault
rateNo
textYes
voiceNoInstalled Windows voice nameMicrosoft Zira Desktop
volumeNo

TDQS

C2.7/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden. It discloses the TTS backend but not whether the call blocks until speech finishes, whether audio is played locally versus returned, whether long text is truncated, or what happens if the named voice is not installed.

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

Conciseness4/5

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

A single front-loaded sentence with zero filler; it states mechanism and effect immediately. It is efficient, though arguably too terse for a 4-parameter tool.

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?

Four parameters, no annotations, no output schema, and 25% schema coverage demand more than one sentence. Nothing is said about side effects, timing, error behavior, or the undocumented rate/volume parameters.

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

Parameters2/5

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

Schema coverage is only 25% – just 'voice' is documented ('Installed Windows voice name'). The description adds nothing about rate, volume, or text semantics (rate range is -10 to 10 with default 2, which is non-obvious and unexplained). It fails to compensate for the low coverage.

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?

States a specific verb (speak) and resource (text, aloud) plus the underlying mechanism (Windows Text-to-Speech). It is clearly distinct in intent from the sibling list_voices, though it never explicitly says so.

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?

No when-to-use guidance, no prerequisites, and no mention of the sibling list_voices even though discovering valid voice names requires it. Usage is only implied by the verb.

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 observedlist_voices
    • First observedspeak
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Scored across 2 tools

Disambiguation5/5

speak and list_voices target entirely distinct actions (produce audio vs. enumerate available voices), with no overlap in purpose. An agent can trivially pick the right tool.

Naming Consistency5/5

Both names follow a clean verb_noun convention (speak, list_voices) with consistent snake_case where multi-word. No mixing of styles.

Tool Count4/5

Two tools is on the thin side, but for a narrow text-to-speech server each tool clearly earns its place. It borders on under-scoped rather than bloated.

Completeness3/5

Core capability (speaking) is present, but list_voices is a partial dead end since there is no way to select a voice, stop/pause playback, or adjust rate/pitch. These are notable gaps for a TTS surface.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers