Skip to main content
Glama
ethan-hub26

embedcalc-mcp

by ethan-hub26

UART Baud Rate / BRR Calculator

embedcalc_uart_baud
Read-onlyIdempotent

Calculate STM32 USART baud rate settings and error from clock and target baud. Returns BRR register, actual baud, error percent, and frame timing.

Instructions

Compute the STM32 USART BRR register (mantissa + fraction), the actual achieved baud rate, and the baud error for a given peripheral clock — plus frame size/character time for the given format.

Args:

  • clock_hz (int): USART peripheral clock in Hz (e.g. 72000000).

  • baud (int): target baud rate (e.g. 115200).

  • oversampling (8|16, default 16): USART OVER8 setting.

  • data_bits (5-9, default 8), parity ('none'|'even'|'odd', default 'none'), stop_bits (1|1.5|2, default 1).

Returns (structured): { mantissa, fraction, brr_hex, actual_baud, error_percent, frame_bits, char_time_us }. Rule of thumb: |error| < 2% total link budget; keep your side < 0.5% when possible. Example: 72 MHz, 115200, over16 -> BRR=0x0271 (mantissa 39, fraction 1), 0.00% error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
baudYesTarget baud rate in bit/s
parityNoParitynone
clock_hzYesUSART peripheral clock in Hz
data_bitsNoData bits per frame
stop_bitsNoStop bits
oversamplingNoOversampling (OVER8): 16 or 8

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
brr_hexYesUSART_BRR register value
fractionYes
mantissaYes
frame_bitsYesstart + data + parity + stop bits
actual_baudYes
char_time_usYesTime per character at actual baud
error_percentYes
Behavior4/5

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds computational specifics (e.g., returns mantissa, fraction, hex value, actual baud, error, frame bits, char time) and a practical example. No contradictions.

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?

The description is well-structured with clear sections (args, returns, rule, example). It is somewhat lengthy but each part adds value. Slightly more concise could be achieved, but overall effective.

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 has an output schema (implied), the description covers all necessary aspects: what it calculates, parameter details, return fields, and a guiding example. It is fully sufficient for an agent to select and invoke correctly.

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?

Input schema has 100% parameter description coverage. The description adds value beyond schema by giving an example and explaining the meaning of parameters in context (e.g., oversampling, parity). It does not repeat schema verbatim but clarifies usage.

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 it computes the BRR register, actual baud rate, error percentage, frame size, and character time for STM32 USART. It specifies the resource (BRR register) and distinguishes from sibling embedcalc tools which cover different calculations.

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 a rule of thumb for acceptable error and an example usage. However, it does not explicitly state when not to use it or mention alternatives. The context makes it clear it's for STM32 USART baud calculation, but could be slightly more explicit.

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

Install Server

Other Tools

Latest Blog Posts

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/ethan-hub26/embedcalc-mcp'

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