Skip to main content
Glama
AlanOgic

Betaflight MCP Server

by AlanOgic
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

set_pid_advanced

DestructiveIdempotent

Modify advanced PID settings on the active Betaflight profile, changing only supplied fields; for firmware 2025.12+, refuses if armed, returns updated values, then call save_config.

Instructions

Modifie des réglages PID avancés du profil actif (noms CLI, voir get_pid_advanced). Seuls les champs fournis changent. simplified_pids_mode=OFF empêche le firmware de recalculer les PIDs depuis les curseurs (ex. au prochain batch CLI). Betaflight 2025.12+ (API >= 1.47) uniquement. Refusé si FC armé. Retourne les valeurs relues. Appeler save_config ensuite.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
settingsYesRéglages à modifier, noms CLI Betaflight 2025.12+ → valeur (entier, ou libellé pour les énumérations). Champs : feedforward_transition (plage firmware [0–100]); acc_limit (plage firmware [0–500]); acc_limit_yaw (plage firmware [0–500]); angle_limit (plage firmware [10–80]); anti_gravity_gain (plage firmware [0–250]); iterm_rotation (valeurs acceptées : OFF, ON); iterm_relax (valeurs acceptées : OFF, RP, RPY, RP_INC, RPY_INC); iterm_relax_type (valeurs acceptées : GYRO, SETPOINT); throttle_boost (plage firmware [0–100]); acro_trainer_angle_limit (plage firmware [10–80]); f_roll (plage firmware [0–1000]); f_pitch (plage firmware [0–1000]); f_yaw (plage firmware [0–1000]); d_max_roll (plage firmware [0–250]); d_max_pitch (plage firmware [0–250]); d_max_yaw (plage firmware [0–250]); d_max_gain (plage firmware [0–100]); d_max_advance (plage firmware [0–200]); use_integrated_yaw (valeurs acceptées : OFF, ON); integrated_yaw_relax (plage firmware [0–255]); iterm_relax_cutoff (plage firmware [1–50]); motor_output_limit (plage firmware [1–100]); auto_profile_cell_count (plage firmware [-1–8]); dyn_idle_min_rpm (plage firmware [0–200]); feedforward_averaging (valeurs acceptées : OFF, 2_POINT, 3_POINT, 4_POINT); feedforward_smooth_factor (plage firmware [0–95]); feedforward_boost (plage firmware [0–50]); feedforward_max_rate_limit (plage firmware [0–200]); feedforward_jitter_factor (plage firmware [0–20]); vbat_sag_compensation (plage firmware [0–150]); thrust_linear (plage firmware [0–150]); tpa_mode (valeurs acceptées : PD, D); tpa_rate (plage firmware [0–100]); tpa_breakpoint (plage firmware [1000–2000]); simplified_pids_mode (valeurs acceptées : OFF, RP, RPY)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (which already flag destructive/idempotent/non-read-only), it discloses partial-update semantics ('Seuls les champs fournis changent'), the armed-state refusal, firmware/API gating, that values are re-read on return, and the persistence requirement via save_config.

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?

Dense but front-loaded: purpose first, then partial-update rule, then the side effect, gating, refusal condition, return behavior and follow-up. Every sentence earns its place, though the run-on sequencing is slightly crowded.

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?

For a mutation tool with a deep nested schema and no output schema, it covers prerequisites, failure conditions, return behavior and the required follow-up call, leaving nothing an agent needs missing.

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% and the single nested object is exhaustively documented per field, so the baseline is 3; the description adds the update-only-provided-fields contract and routes the agent to get_pid_advanced for valid CLI names, plus the simplified_pids_mode side effect.

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?

States a specific verb (Modifie) plus resource and scope (réglages PID avancés du profil actif), and points to get_pid_advanced for CLI field names, which cleanly separates it from the getter and from set_pid_values.

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?

Gives concrete sequencing guidance ('Appeler save_config ensuite') and a prerequisite (Betaflight 2025.12+/API 1.47, refusé si FC armé), plus a semantic warning about simplified_pids_mode=OFF. It does not explicitly contrast with set_pid_values, so it falls short of full when-not routing.

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