Skip to main content
Glama
Sign In
Betaflight MCP

Betaflight MCP

by bvandevliet
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

set_i2c3_pullup

Enable internal pull-up resistors on I2C bus 3 to improve signal integrity and reduce noise on the bus.

Instructions

Set i2c3_pullup: Enable internal pull-up resistors on I2C bus 3. (Requires: USE_I2C_DEVICE_3) [UINT8, default: OFF]

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": {
      "value": "<value>"
    },
    "name": "set_i2c3_pullup"
  }
}

Input Schema

NameRequiredDescriptionDefault
valueYesValue for i2c3_pullup (UINT8)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0-alpha

TDQS

A4.1/5.0
Behavior3/5

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

Discloses that it enables pull-ups, requires a compile option, and mentions a default value 'OFF'. However, it does not describe side effects (e.g., persistence, reboot required) or the valid range of the UINT8 value. Without annotations, the description carries the burden but provides only basic info.

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?

Extremely concise: a single sentence with a parenthetical note and a type/default hint. No wasted words; information is front-loaded.

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?

Covers the core function, prerequisite, and default. However, it lacks clarifications on accepted input values (e.g., is 0 off? any non-zero on?) and behavioral details like whether changes are persisted immediately or require reboot. For a simple set tool, this is adequate but not fully complete.

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?

Adds meaning beyond the input schema. The schema description is 'Value for i2c3_pullup (UINT8)' which is vague. The description clarifies the semantic purpose ('enable internal pull-up resistors') and notes the default value, compensating for the schema's minimal description.

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 the action: 'Enable internal pull-up resistors on I2C bus 3.' The verb 'Enable' and resource 'I2C bus 3' are specific, and the bus number distinguishes it from siblings like set_i2c1_pullup and set_i2c2_pullup.

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?

Mentions a prerequisite: 'Requires: USE_I2C_DEVICE_3', which informs when the tool is applicable. However, it does not explicitly list alternatives or state when not to use it beyond the missing compile-time option.

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