Loading ToolBench
S7-MCP-Bridge is a MCP Server that connects AI agents to Siemens industrial PLCs (specifically S7-1500 and S7-1200 models).
S7-MCP-Bridge exposes 17 industrial PLC control tools with generally adequate naming and descriptions, but exhibits significant gaps in schema completeness, parameter validation, and error guidance. Tools follow verb-noun patterns (Alarms-Acknowledge, Api-Login, PlcProgram-Read) which is good, but many input schemas lack full parameter constraints (enums, min/max bounds), descriptions are moderately detailed but sometimes repetitive, and error handling is minimal, most tools return raw API responses without recovery guidance. The server accepts IP address and credentials as parameters, which creates security concerns around credential handling. Output schemas are not formally documented. Schemas themselves are visible in source code (using Zod), which is positive, but several parameters are optional without justification, and sensitive operations (password changes, logins) lack confirmation patterns.
Use this method to acknowledge individual alarms. To call the Alarms.Acknowledge method, you need the "acknowledge_alarms" permission. Possible error messages: 2 Permission denied || The current authentication token is not authorized to call this method. Log in with a user account that has sufficient authorizations to call this method
With this method you can determine which alarms are currently active on the CPU, and when the last change occurred within the diagnostics buffer. To call the Alarms.Browse method, you need the "read_diagnostics" permission.
The Api.Browse method gives you a list of all methods that you can call via the Web API with the current firmware. This provides you with an overview of all the methods supported by the CPU. No authorization is required for calling the Api.Browse method.
You can change the password for a user account with the Api.ChangePassword method. Recommendation: Before changing a password, read the password policy from the CPU using the Api.GetPasswordPolicy API method. If the new password does not conform to the password policy of the CPU, a corresponding error message is returned. No prior authorizations are required to call the Api.ChangePassword method, but you must enter the current password for this call.
Credentials passed as tool parameters instead of server-side secret injection. plcIpAddress appears in every tool, creating audit trail exposure and requiring agents to manage IP→credential mapping.
Api-ChangePassword and Api-Login lack confirmation/dry-run patterns despite being irreversible or sensitive operations. No recovery guidance if credentials are changed or session created in error.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 45 | - | v1 |
You use the Api.DeleteTicket method to delete a ticket provided by the system that is assigned to the current user session. To call the Api.CloseTicket method, you do not need an authorization but a valid session token.
Passwords must fulfill specific criteria to be secure. The Api.GetPasswordPolicy method provides you with the password policy of the CPU. The password policy is a global setting in the STEP 7 project and applies for all users of the Web server. The method does not contain any information on the expiration of the password. Any user, including unauthenticated users ("Anonymous"), can call this API method. No authorization is required for calling the Api.GetPasswordPolicy method.
After the successful login, the Api.GetPermissions returns a list of actions for whose execution the user is authorized.
The Api.GetQuantityStructures method returns different structure information of the Web server.
The Api.Login method checks the login data of the user and on successful verification opens a new Web API session. The method requests the username and the password of the user in plain text as proof of authorization. Remember to ask the User for the username and password. Once the user has been successfully authenticated, the method returns a token that must be sent with every subsequent Web API request in order to authorize the request. The token is valid until the user logs out with the Api.Logout method or until the session expires due to inactivity. The duration of a session can be configured in the CPU under "Web server / Web services" in the TIA Portal. If a session expires, the user must log in again with the Api.Login method to obtain a new token. The user name and the password are encrypted before they are transferred to the server.
The Api.Logout method removes the token from the list of active Web API sessions and ends the session. The Api.Logout method returns the status of whether the logout was successful or not. For security reasons, however, the method always returns the Boolean value "true" even if the token is invalid.
The Api.Ping method outputs a unique ID for the CPU used. You can use it to determine whether the CPU can be reached. The CPU ID comprises a 28-byte string. The system assigns a new, unique CPU ID after each restart (POWER ON - POWER OFF) or warm start of the CPU. By comparing this with previously output IDs, you can also determine whether the CPU was restarted in the meantime. No authorization is required for calling the Api.Ping method.
Use the Api.Version method to request the current version number of the Web API. You can draw conclusions from the version number: • The functions supported by the CPU version • The hardware functional status of the CPU This information lets you implement applications that dynamically adapt to the scope of functions offered by the contacted CPU. An application can support multiple CPU versions. No authorization is required for calling the Api.Version method
With this method you read out entries from the diagnostics buffer of the CPU. To call the DiagnosticBuffer.Browse method, you need the "read_diagnostics" permission.
The AvailablePlcs method outputs a list of all configured PLCs with their names and IP addresses. No authorization is required for calling the Available-Plcs method.
With this API method, you request a ticket to create a backup file of the CPU configuration. If all resources have been exhausted in current user session, you should close existing tickets to free up resources by calling the method Api.CloseTicket. Then call Plc.CreateBackup method again to create a backup file. To call the Plc.CreateBackup method, you need the "backup_plc" permission.
The PlcProgram.Browse method allows you to search for tags and the corresponding metadata according to your individual requirements. To call the PlcProgram.Browse method, you need the "read_value" authorization.
Use the this method to read a single variable from a CPU. To call the PlcProgram.Read method, you need the "read_value" authorization.
Multiple parameters accept optional objects (filters, etc.) without schema constraints. 'filters' in Alarms-Browse and DiagnosticBuffer-Browse are typed as 'object' with no enum/constraint documentation, inviting invalid filter structures.
No output schemas documented. Tools return JSON.stringify() of API responses without specifying expected fields, making it impossible for LLMs to plan downstream tool calls or extract necessary IDs.
Error handling returns raw error messages without actionable recovery guidance. Example from source: 'catch (err: any) { return `Tool 'Alarms-Acknowledge' || Error: ${JSON.stringify(err.message)}` }' provides no hint on whether to retry, check permissions, or adjust input.
Api-ChangePassword accepts 'password' and 'new_password' as bare string parameters with no description of format, length, or character requirements. Users/agents cannot validate inputs before calling.
PlcProgram-Browse 'mode' parameter is described as 'Enumeration that determines the behavior of this method' but no enum values are provided in schema or description, forcing agents to guess.
No pagination support documented or implemented. Browse tools (Alarms-Browse, DiagnosticBuffer-Browse) accept 'count' parameter but no next_cursor, offset, or total_count guidance. Responses could exceed context window.
Tools do not declare permission requirements in descriptions. Descriptions mention 'you need the X permission' but do not specify what scope or authorization level is required in structured form.
No idempotency guarantees stated. Agents may retry on transient failures, but tools like Api-Login, Api-ChangePassword, Alarms-Acknowledge could create duplicates or unwanted side effects on retry.