AT Bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| at_list_portsA | List all available COM/serial ports. Returns device name, description, hardware ID, VID/PID. |
| at_configureA | Configure serial port parameters (baud rate, data bits, parity, stop bits, flow control). Can be called before or after opening the port. |
| at_open_portB | Open the specified COM port and establish a serial connection. |
| at_close_portB | Close the currently opened COM port connection. |
| at_auto_detectA | Auto-detect all available COM ports. Tries common baud rates and sends an AT probe command to find responsive devices. Useful when unsure which port the device is connected to. |
| at_send_commandA | Send an AT command to the connected device and read the response. Auto-prepends AT prefix (e.g. 'CSQ' becomes 'AT+CSQ'). Supports standard AT and extended AT+ commands. |
| at_batch_testA | Batch-test AT commands. Sends a list of AT commands to the connected device and returns all results with automatic classification (PASS/OK/ERR/CME). Much more efficient than calling at_send_command repeatedly; good for validating a command list from the knowledge base. |
| at_knowledge_searchA | Search the AT command knowledge base. Supports filtering by keyword (key/name/description/AT string) and source (3gpp/vendor/custom). |
| at_knowledge_chipsetsA | List available chipset knowledge base files. AI should call this first to know which platforms exist, then use at_knowledge_add to write to the appropriate platform file. |
| at_knowledge_addA | Add or update an AT command in the knowledge base. Stores in the specified chipset file (e.g. asr, quectel) or _custom. Use at_knowledge_chipsets to see available platforms. |
| at_knowledge_listA | List all commands in the knowledge base, optionally filtered by source. Shows key, name, and expected response summary. |
| at_knowledge_statsA | Show knowledge base statistics: total commands, per-source YAML file breakdown, source distribution. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Tools are mostly distinct, but at_auto_detect and at_list_ports both deal with port discovery and may cause confusion. at_batch_test and at_send_command are clearly differentiated by batch vs single command. Knowledge base tools are well-separated.
All tools start with 'at_' prefix. Most follow verb_noun pattern (at_open_port, at_list_ports), but knowledge base tools use noun_verb (at_knowledge_add, at_knowledge_list), and at_configure is a standalone verb. Minor inconsistency but overall predictable.
12 tools is well-scoped for the domain of AT command interaction and knowledge management. It covers port operations, command sending, and knowledge base without being excessive.
Core workflow is covered: port detection (auto_detect, list_ports), configuration (configure), open/close, and command sending (single/batch). Knowledge base adds support. Missing possibly a 'read current config' or raw send without AT prefix, but these are minor gaps.