What can you do with this server?

It is an MCP server for Bangladesh couriers that lets you list couriers, create and track parcels, check balances, and resolve location IDs. * list_couriers — Show supported couriers and whether each has active credentials. * create_parcel — Book a delivery with Steadfast, Pathao, RedX, or Paperfly using recipient details, COD amount, invoice id, and courier-specific meta (e.g., Pathao store/city/zone/area IDs). * track_parcel — Look up a shipment's status by consignment ID, invoice, or tracking code. * get_balance — Check the merchant's account balance for a courier (Steadfast/Pathao). * get_courier_locations — Resolve city, zone, and area IDs for couriers like Pathao. * check_fraud_risk — The README also advertises a fraud-risk score for Bangladeshi phone numbers.

How do I use Aura Courier MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Aura Courier MCP Track parcel invoice A-1001" 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.

Aura Courier MCP

by auraajenticai

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

🚀 Aura Courier MCP — Bangladesh's First Universal Courier Model Context Protocol

Glama Verified License: MIT MCP SDK Couriers

One unified Model Context Protocol connector for every Bangladesh courier. Book deliveries, track parcels, check merchant balances, and screen customer COD/return-fraud risk — straight from Google Antigravity, Claude Desktop, Cursor, n8n AI Agents, or any MCP-compatible client. Just tell your AI what to ship.

🌐 Showcase & live docs: courier.auraajenticai.cloud 🏢 Built by: Aura Ajentic AI · Khondokar Towsif (Amirul Islam Redwan)

⚡ Supported couriers — four networks, one interface (all proven)

Courier	API	Status
Steadfast	Packzy API v1	✅ Proven
Pathao	Aladdin API v1 (OAuth + city/zone resolver)	✅ Proven
RedX	OpenAPI v1 (area auto-resolver + tracking)	✅ Proven
Paperfly	Wingman API (order + tracking)	✅ Proven

You bring each courier's own merchant credentials (env vars or request headers); Aura routes the request and normalizes the response.

Related MCP server: renfield-mcp-tracking

🧠 MCP tools

Tool	What it does
`create_parcel`	Book a parcel on Steadfast / Pathao / RedX / Paperfly (or `auto`), with one normalized response.
`track_parcel`	Universal tracking by tracking / consignment / reference id, across every supported courier.
`get_balance`	Live merchant account balance & payout info (Steadfast & Pathao).
`check_fraud_risk`	BD phone COD/return-risk score — screen a customer's number before you ship cash-on-delivery. Works with no courier keys.
`list_couriers`	Show supported couriers and which credentials are currently active.

🔌 Two ways to connect

1) Remote URL — claude.ai web, n8n, any remote client

Add a custom MCP connector and pass your courier keys as headers (or query params):

https://courier.auraajenticai.cloud/mcp

Headers: x-steadfast-api-key, x-steadfast-secret-key, x-pathao-client-id, x-pathao-client-secret, x-pathao-username, x-pathao-password, x-redx-api-token, x-paperfly-api-key, x-paperfly-store-name, x-paperfly-username, x-paperfly-password.

2) Local (npx / STDIO) — Antigravity, Claude Desktop, Cursor

Add only the couriers you use — each is independent. Your keys stay on your side (env vars or request headers); Aura never stores them.

🪐 Google Antigravity / Gemini CLI — `antigravity.json`

{
  "mcpServers": {
    "aura-courier": {
      "command": "npx",
      "args": ["-y", "aura-courier-mcp@latest"],
      "env": {
        "STEADFAST_API_KEY": "YOUR_STEADFAST_API_KEY",
        "STEADFAST_SECRET_KEY": "YOUR_STEADFAST_SECRET_KEY",
        "REDX_API_TOKEN": "YOUR_REDX_TOKEN",
        "PAPERFLY_API_KEY": "YOUR_PAPERFLY_KEY",
        "PAPERFLY_STORE_NAME": "YOUR_STORE_NAME",
        "PAPERFLY_USERNAME": "YOUR_PAPERFLY_USERNAME",
        "PAPERFLY_PASSWORD": "YOUR_PAPERFLY_PASSWORD"
      }
    }
  }
}

⚡ Claude Desktop — `claude_desktop_config.json` & 💻 Cursor / VS Code — `settings.json`

{
  "mcpServers": {
    "aura-courier": {
      "command": "npx",
      "args": ["-y", "aura-courier-mcp@latest"],
      "env": {
        "STEADFAST_API_KEY": "YOUR_STEADFAST_API_KEY",
        "STEADFAST_SECRET_KEY": "YOUR_STEADFAST_SECRET_KEY"
      }
    }
  }
}

📋 Courier notes

Steadfast / Pathao — API key + secret (Pathao also needs client id/secret + username/password). get_balance is available for these two.
RedX — API access token (REDX_API_TOKEN); delivery area is auto-resolved from the address, or pass delivery_area_id.
Paperfly — needs the paperflykey and your merchant username/password on both create and track, plus your store name.
check_fraud_risk runs keyless — a COD gate you can call before booking anything.

💬 Then just ask your AI

"Book a Steadfast parcel for invoice A-1001, COD 1500 to 017XXXXXXXX." "Create a RedX parcel to Dhanmondi, COD 900." "Track consignment 20A316MOG0DI." "Check the return risk for 018XXXXXXXX before I ship COD."

🏗️ Architecture

AI agent (Antigravity / Claude / Cursor / n8n)
        │   MCP (STDIO or Streamable-HTTP)
        ▼
  Aura Courier MCP  ──►  Registry (gateway + smart router)  ──►  Courier adapters
                                                                 ├── Steadfast  (Packzy API)
                                                                 ├── Pathao     (Aladdin API)
                                                                 ├── RedX       (OpenAPI)
                                                                 └── Paperfly   (Wingman API)
                                                        + built-in BD phone fraud-risk engine

Keys are read per-request (headers) or per-process (env) — never persisted.

🔒 Privacy Policy

Aura Courier MCP processes only what's needed to fulfil your request: your courier credentials (passed per-request as headers/env — never stored by Aura), the order details you send to book/track a parcel, and phone numbers you submit to check_fraud_risk. Order data is forwarded only to the courier you choose (Steadfast / Pathao / RedX / Paperfly) to complete the operation; nothing is sold or used for profiling, and credentials live only in memory for the active session. All traffic is over HTTPS.

Full policy: https://courier.auraajenticai.cloud/privacy · Contact: ceo@auraajenticai.cloud

📜 The vision

মানুষের স্বপ্ন · এআই-এর হাত Aura is building Bangladesh's native agentic-commerce layer — unifying courier logistics, digital payments, and AI automation so any AI in the world can natively transact with Bangladeshi businesses. This MCP is the first brick.

Licensed under MIT © Aura Ajentic AI.

Available Tools

5 tools

create_parcelCreate a courier parcel (book a delivery)A

Book a delivery with a Bangladesh courier. Returns the consignment id and tracking code. COD amount is in BDT (use 0 for prepaid). The invoice must be unique per order. Pathao also needs meta:{ storeId, cityId, zoneId, areaId } — resolve the IDs with get_courier_locations.

ParametersJSON Schema

Name	Required	Description	Default
`meta`	No	Courier-specific extras. Pathao: { storeId, cityId, zoneId, areaId }.
`note`	No
`courier`	No	Which courier to book with.	steadfast
`invoice`	Yes	Your unique order/invoice id (idempotency key).
`codAmount`	Yes	Cash-on-delivery amount in BDT (0 = prepaid).
`recipientName`	Yes
`recipientPhone`	Yes
`itemDescription`	No
`recipientAddress`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations indicate non-readonly and non-destructive; description adds that it creates a booking, uses invoice as idempotency key, and returns consignment/tracking. No contradiction, but does not mention rate limits or error handling.

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?

Three concise sentences, front-loaded with purpose, followed by essential details. No redundant information.

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

Completeness4/5

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

Given 9 parameters and nested meta object, description addresses key nuances (idempotency, COD unit, Pathao ID resolution). Lacks mention of duplicate invoice handling and error scenarios, but overall sufficient for selection and invocation.

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?

Schema covers 44% of params with descriptions; description adds meaning to codAmount (BDT, 0=prepaid), invoice (unique per order), and meta (Pathao structure with ID resolution). Other params like recipientName and address lack extra context but schema provides types.

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

Purpose5/5

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

Clearly states booking a delivery with Bangladesh courier, returns consignment id and tracking code. Distinguishes from siblings like list_couriers or track_parcel.

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

Usage Guidelines4/5

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

Provides guidance on COD amount unit, invoice uniqueness for idempotency, and need to resolve IDs via get_courier_locations for Pathao. Could explicitly state when not to use or alternatives, but context from sibling tools helps.

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

get_balanceGet courier account balanceB

Read-only

Get the merchant's current account balance with a courier (BDT).

ParametersJSON Schema

Name	Required	Description	Default
`courier`	No		steadfast

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the balance is 'current' and in BDT, but does not disclose further behavioral traits like error handling or constraints. No contradiction with annotations.

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 concise sentence that front-loads the purpose. No unnecessary words.

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?

Given the low complexity (one optional parameter, no output schema), the description is somewhat adequate but lacks detail about the return value or what 'balance' means (e.g., monetary balance, units). Could be more informative.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not mention the 'courier' parameter at all. It does not explain the enum values, the default, or its optional nature.

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

Purpose5/5

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

The description clearly specifies the verb 'Get', the resource 'merchant's current account balance', and the scope 'with a courier (BDT)'. It distinguishes this tool from siblings like 'list_couriers' and 'create_parcel'.

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 guidance on when to use this tool versus alternatives, no prerequisites, no situations to avoid. The description simply states what it does without usage context.

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

get_courier_locationsResolve courier location IDs (city / zone / area)A

Read-only

For couriers that address by structured location IDs (e.g. Pathao). Get the list of cities, or the zones of a city (parentId = city id), or the areas of a zone (parentId = zone id). Use the returned ids in create_parcel's meta for Pathao.

ParametersJSON Schema

Name	Required	Description	Default
`level`	Yes
`courier`	No		pathao
`parentId`	No	Required for zone (city id) and area (zone id).

TDQS

A4.7/5.0

Behavior5/5

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

Beyond annotations (readOnlyHint, openWorldHint), the description explains the hierarchical traversal pattern (city->zone->area via parentId) and the relationship to create_parcel. No contradictions with annotations.

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?

Two concise sentences that front-load the main purpose and immediately follow with usage guidance. Every sentence earns its place without fluff.

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

Completeness5/5

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

Given the tool's simplicity (hierarchical lookup of location IDs), the description fully covers what it does, how to navigate levels, and how to use the output. No output schema needed; return values are implied.

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?

With only 33% schema description coverage, the description adds meaning by explaining the hierarchical dependency (parentId for zone/area) and providing usage context. It clarifies the enum behavior implicitly and mentions the default courier.

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

Purpose5/5

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

The description clearly states the tool fetches hierarchical location IDs (cities, zones, areas) for couriers like Pathao. It specifies the verb 'get' and the resource 'structured location IDs', distinguishing it from siblings such as list_couriers which lists couriers, and create_parcel which uses these IDs.

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

Usage Guidelines4/5

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

It explicitly states the tool is 'For couriers that address by structured location IDs (e.g. Pathao)' and explains how to use the resulting IDs in create_parcel. While it doesn't state when not to use it, the context is clear and sufficient.

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

list_couriersList supported couriersA

Read-only

List every courier this connector supports and whether each is configured with credentials.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the description adds value by specifying the output includes credential configuration status. No contradiction exists, and the description complements the annotations effectively.

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 two sentences long with no extraneous words. It front-loads the core functionality (listing couriers) and adds a key detail (credential status) efficiently.

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

Completeness4/5

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

Given no parameters or output schema, the description provides sufficient context: it lists couriers and their credential configuration. However, without an output schema, the exact structure is unspecified, which is a minor 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?

No parameters exist, and schema coverage is 100%. The description adds no param info (not needed), but clearly states the scope of output (all couriers with credentials status), which aids understanding.

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

Purpose5/5

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

The description clearly states the tool lists all supported couriers and indicates whether each is configured with credentials. The verb 'list' and resource 'couriers' are specific, and the description distinguishes from sibling tools (e.g., get_courier_locations) which likely return different data.

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 guidance on when to use this tool versus alternatives like get_courier_locations or track_parcel. The description does not mention prerequisites or context, leaving the agent to infer usage from the name alone.

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

track_parcelTrack a parcel's delivery statusA

Read-only

Look up the current delivery status of a parcel. Provide any ONE of: consignmentId, invoice, or trackingCode.

ParametersJSON Schema

Name	Required	Default
`courier`	No	steadfast
`invoice`	No
`trackingCode`	No
`consignmentId`	No

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true and openWorldHint=true. The description is consistent, stating 'Look up' which implies read-only behavior. No additional behavioral traits (e.g., rate limits, auth) are disclosed, so the description adds no extra value beyond annotations.

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 extremely concise with two short sentences. Every word is informative and there is no fluff or repetition.

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?

For a simple lookup tool with no output schema, the description is adequate but incomplete. It omits details about the response format, possible errors, and the courier parameter's role. This leaves some ambiguity for the agent.

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 description coverage is 0%, so the description must compensate. It lists three parameter names (consignmentId, invoice, trackingCode) and says to use any one, but does not explain their formats, constraints, or the courier parameter. The enum for courier is not mentioned. This provides only minimal semantic help.

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

Purpose5/5

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

The description clearly states 'Look up the current delivery status of a parcel,' which is a specific verb+resource combination. It also distinguishes from sibling tools (list_couriers, create_parcel, etc.) by focusing on tracking.

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

Usage Guidelines4/5

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

The description provides explicit guidance on parameter selection: 'Provide any ONE of: consignmentId, invoice, or trackingCode.' However, it does not discuss when not to use this tool or potential alternatives, but given sibling tools are very different, this is sufficient.

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. Dates show when Glama detected each change.

5 tool updatesv0.1.0Jul 29, 2026
- First observedcreate_parcel
- First observedget_balance
- First observedget_courier_locations
- First observedlist_couriers
- First observedtrack_parcel

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing couriers, creating parcels, tracking, checking balance, and resolving location IDs. There is no overlap or ambiguity between the tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (list_couriers, create_parcel, track_parcel, get_balance, get_courier_locations), making the set predictable and easy to navigate.

Tool Count5/5

With five tools, the server is well-scoped for its purpose. Each tool covers an essential operation without unnecessary bloat or gaps.

Completeness4/5

The set covers core workflows (list, create, track, balance, location resolution). Missing update/cancel operations, but for a basic courier API this is acceptable.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

mcp
com.api2cart
Unified MCP server for 70+ eCommerce platforms: products, orders, customers, and more.
E-commerce & Retail CRM
1
ComOS Federation A
io.github.ronrey
Multi-tenant MCP gateway for AI commerce. One connection, every store.
E-commerce & Retail Agent Orchestration
451
ComOS Federation Gateway A
io.github.ronrey
Multi-tenant MCP gateway for AI commerce. One connection, every store.
E-commerce & Retail Agent Orchestration
451
ComOS Federation Gateway B
com.comos-federation
Multi-tenant MCP gateway for AI commerce. One connection, every store.
E-commerce & Retail Agent Orchestration
451

Related MCP Servers

bluedart-mcp-server
Travel & Transportation E-commerce & Retail
nidhiyashwanth
F
license
A
quality
D
maintenance
MCP server for BlueDart (DHL eCommerce India) shipping API enabling waybill creation, tracking, pickup scheduling, and transit time lookup via MCP tools.
Updated 5 months ago (2026-04-19 17:53 UTC)
8
-
renfield-mcp-tracking
E-commerce & Retail Travel & Transportation
ebongard
A
license
A
quality
D
maintenance
Multi-carrier parcel tracking server that communicates directly with carrier APIs (DHL, UPS, FedEx, etc.) without third-party aggregators, providing normalized tracking status and events.
Updated 3 months ago (2026-06-18 09:10 UTC)
3
MIT
WariMCP
Payments & Billing Finance
Bigabou007-dev
A
license
A
quality
B
maintenance
A unified MCP server for West African payment providers, enabling AI agents and REST clients to initiate payments, payouts, refunds, and manage webhooks across 10 providers with a single API.
Updated a month ago (2026-08-06 23:21 UTC)
8
10
MIT
shiplabel-mcp
E-commerce & Retail
xentral
A
license
A
quality
C
maintenance
Carrier-agnostic shipping labels as a self-hostable MCP server. Build one shipment request, get a tracking number and a print-ready label back for DHL, DPD, UPS, FedEx, GLS, Sendcloud, and Shipcloud.
Updated 2 months ago (2026-07-15 06:03 UTC)
3
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/auraajenticai/aura-courier-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

🚀 Aura Courier MCP — Bangladesh's First Universal Courier Model Context Protocol

⚡ Supported couriers — four networks, one interface (all proven)

🧠 MCP tools

🔌 Two ways to connect

1) Remote URL — claude.ai web, n8n, any remote client

2) Local (npx / STDIO) — Antigravity, Claude Desktop, Cursor

🪐 Google Antigravity / Gemini CLI — antigravity.json

⚡ Claude Desktop — claude_desktop_config.json & 💻 Cursor / VS Code — settings.json

📋 Courier notes

💬 Then just ask your AI

🏗️ Architecture

🔒 Privacy Policy

📜 The vision

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

🪐 Google Antigravity / Gemini CLI — `antigravity.json`

⚡ Claude Desktop — `claude_desktop_config.json` & 💻 Cursor / VS Code — `settings.json`