Loading ToolBench
MCP server for OpenAirInterface 5G configuration management, providing tools to configure gNB and UE parameters, manage bandwidth settings, retrieve logs and measurements, and access OAI documentation
This server has significant definition quality gaps. Of 15 tools, only tools 1-7 are in the primary server.py file with visible implementations. Tools 8-15 are split across alt_server.py and server_backup.py (backup file with unclear maintenance status). Schema definitions are present but sparse, most tools have incomplete parameter descriptions, vague guidance on when to use them, and minimal output documentation. Naming is verb-first (good pattern), but many descriptions lack the specificity needed for LLM tool selection. Error handling is minimal; no recovery guidance or actionable error messages visible. The primary concern is that tools expose low-level configuration file manipulation (set_parameter, apply_parameter, set_oai_parameter, etc.) without clear guidance on dependencies, format validation, or side effects. The 'confirmation' parameter pattern (tools 9, 12, 13, 15) is a workaround for confirming destructive actions but is not integrated with a proper confirmation-request pattern. Overall, descriptions are too brief (avg ~80 chars, well below baseline 194), parameter descriptions are generic, and output schemas are not documented.
Sets nr_cellid in the matching .conf file after confirmation.
Sets or adds a parameter in the matching OAI .conf file after confirmation.
Sets tx_gain in the matching .conf file after confirmation.
Apply a previously staged parameter modification to an OAI .conf file. Supports replacing existing entries or adding new ones, optionally under a specific config section.
Retrieves recent logs from the gNB container and extracts key measurements and configuration parameters for monitoring gNB status
Retrieves recent logs from the UE container and extracts key measurements for monitoring UE status and connectivity
Output schemas not documented. Tools like get_gnb_logs, get_ue_logs, and all set/apply tools have no documented return type or field structure. LLMs cannot plan downstream tool calls without knowing what fields to expect.
Parameter descriptions are too generic or missing critical constraints. 'hardware' is described as 'Hardware identifier (exact token)' without examples of valid tokens or where to find them. 'new_value' in set_parameter is just 'Desired value (string or numeric)', no guidance on format, escaping, or constraints. This forces LLMs to guess.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Restarts the gNB container in the OAI 5G RF simulator. This tool executes a script that restarts the gNB container and waits for it to become healthy. If UE docker parameters were modified, restart the UE container using the restart_ue tool.
Restarts the UE container in the OAI 5G RF simulator to apply configuration changes
Sets nr_cellid in the matching .conf file based on hardware and optional band.
Sets or adds a parameter in the matching OAI .conf file.
Stage a parameter modification in an OAI .conf file without applying it. This informs the user which file and parameter will change.
Sets tx_gain in the matching .conf file based on hardware and band (optional).
Updates bandwidth-related parameters in the gNB YAML configuration file for Band 78. This tool configures the gNB bandwidth to either 20MHz or 40MHz and automatically sets the appropriate carrier bandwidth and BWP parameters according to 3GPP standards. You should restart the gNB to apply changes.
Sets ssPBCH_BlockPower in the gNB YAML configuration file in the known CONF_DIR. You should restart the gNB to apply the change in the network.
Updates UE configuration parameters including bandwidth settings. Modifies the UE YAML configuration file to match gNB settings for proper network synchronization.
Multiple overlapping tools with unclear differentiation. Tools 8, 9, 14, 15 all set OAI configuration parameters, set_parameter vs apply_parameter vs set_oai_parameter vs apply_confirmed_parameter. LLMs will struggle to pick the right one. Consolidate into a single parameterized tool or clarify the staged vs. direct execution path.
Error handling has no recovery guidance. The code shows FileNotFoundError and ValueError exceptions (in alt_server.py find_conf_file), but tool descriptions do not explain what the LLM should do if a config file is not found (e.g., 'Try searching available configs' or 'Call discover_config_files first').
Confirmation parameter pattern (tools 9, 12, 13, 15) is ad-hoc. A 'confirmation: bool' flag forces the LLM to call the tool twice, once to see what will happen, once with confirmation=True. This is inefficient. Instead, use a dedicated confirmation-request pattern (Multi-Round-Trip Requests) or combine staging and application into a single idempotent call.
Tool descriptions do not explain when to use each tool or dependencies between them. E.g., update_gnb_bandwidth says 'You should restart the gNB to apply changes', but update_ue_parameters does not say whether UE restart is required. And no description explains: should bandwidth be set on gNB first, then UE? Or are they independent?
Tools 10-15 are in server_backup.py, which is not imported or registered in the main server. These tools are likely dead code. Either delete them or integrate them properly into the active server.
No idempotency or side-effect guarantees. Tools like restart_gnb and restart_ue have no documentation about whether they are idempotent. If an agent retries a restart call due to a transient failure, will it restart twice (bad) or detect that it's already running and skip (good)? This is critical for agent reliability.
Parameter 'lines' in get_gnb_logs and get_ue_logs has no constraint. What is the max? What is the default? If an agent passes 1,000,000, will it timeout or exhaust memory? Specify min/max bounds and recommend defaults.