Skip to main content
Glama
Sign In
AT Bridge

AT Bridge

by zeng-andrew
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

at_send_command

Send AT commands to connected IoT devices and read responses. Supports standard AT and extended AT+ commands with optional stop string.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "command": "<command>"
    },
    "name": "at_send_command"
  }
}

Input Schema

NameRequiredDescriptionDefault
commandYesAT command to send. Examples: 'AT', 'AT+CGMI', 'AT+CSQ', 'AT+CREG?', or omit AT prefix like 'CGMI', '+CSQ'.
read_untilNoOptional. Stop reading after encountering this string.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses auto-prepending and command support but does not mention side effects, rate limits, error behaviors, or response format. Some behavior is transparent but not comprehensive.

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: first states the main purpose, second adds clarifying details. No redundant words, front-loads the action.

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 command-send tool, the description covers core behavior and parameter usage. However, it lacks usage guidelines, behavioral details, and return value explanation, which would improve completeness.

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 coverage is 100% with detailed parameter descriptions. The description adds value by explaining auto-prepending behavior and providing examples, going beyond the schema's parameter descriptions.

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?

Description clearly states the verb 'Send', resource 'AT command', and action 'read the response'. It explains auto-prepending of 'AT' prefix and support for standard and extended commands, effectively distinguishing from sibling tools like at_batch_test and at_configure.

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?

Description does not explicitly provide when-to-use or when-not-to-use guidance. It implies usage for sending individual AT commands but lacks comparison with siblings like at_batch_test for batch commands or at_auto_detect for automatic detection.

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

Deploy Server

Other Tools