Loading ToolBench
MCP server for the OutSystems LifeTime REST API v2 — manage deployments, users, teams and applications conversationally.
Strong foundation with 22 well-named tools following verb_noun convention (get_, create_, update_, delete_, list_, manage_). All tools have descriptions (avg 156 chars, within 10-1024 baseline). Input schemas present and properly typed with JSON Schema. However, output schemas are undocumented, LLMs cannot predict response structure for chaining. Parameter descriptions are present but inconsistent in depth; some lack format/constraint guidance. Error handling delegates to LifeTimeAPIError wrapper but lacks recovery guidance in tool descriptions. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification in metadata.
Creates a new application in a given environment using a template. Workflow: (1) get_environments → EnvironmentKey, (2) get_environment_templates → TemplateKey, (3) list_teams or create_team → TeamKey, (4) create_application.
Creates a new database connection in an environment. The Payload object holds the connection configuration; required fields depend on the DatabaseProvider. Call list_db_connection_providers first to see what's supported.
Discards (deletes) a specific application version. This is irreversible. The version cannot be deleted if it is currently running in any environment.
Permanently deletes a database connection from an environment. Applications using it will lose access — verify dependencies first.
Returns the details of a single application (key, name, kind, team, icon, description). Use get_applications to discover ApplicationKeys.
Output schemas undocumented. Tool descriptions state what is returned (e.g., 'Returns the list of...') but do not specify field names, types, or structure. LLMs cannot predict response shape for chaining or field extraction.
Payload parameters (create_db_connection, update_db_connection, test_db_connection) accept generic 'object' type with vague description 'Common fields: Name, DatabaseProvider, Server...' No schema validation, no enum constraints for DatabaseProvider, no required field specification per provider type.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification in metadata. Destructive tools (delete_application_version, delete_db_connection) lack explicit destructiveHint annotation to warn agents.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
Returns the configuration values (site properties, timer schedules, REST endpoints) for a given application across every environment where it is deployed. Useful for auditing per-environment settings and spotting drift between DEV/QA/PRD. Use update_application_configurations to modify a value.
Returns the details of a specific application version, including modules and changelog. Use list_application_versions to find VersionKeys.
Returns all applications across the OutSystems infrastructure. Use IncludeEnvStatus=true to get per-environment deployment status and application version keys (needed for create_deployment). Use IncludeModules=true to also retrieve module-level details (requires IncludeEnvStatus=true). The response includes Keys, Names, Teams, and per-environment statuses.
Returns the configuration details of a specific database connection. Passwords are typically masked in the response.
Returns the permission level a specific role has on a database connection.
Returns the permission level a specific user has on a database connection.
Returns the list of application templates available in a given environment (e.g. Reactive Web App, Mobile App, Service). The TemplateKey returned here is required by create_application. Always call this before creating an application to pick the right template.
Lists all versions of a given application, each with its VersionKey, version label, creation date and changelog. Useful for picking a specific version to deploy or discard.
Lists all valid permission-level keys that can be granted on database connections (e.g. "None", "Read", "ReadWrite"). Call before manage_db_connection_role_permission or manage_db_connection_user_permission.
Lists the database providers available in an environment (e.g. SqlServer, Oracle, MySQL). Use this to discover valid DatabaseProvider keys before creating a connection.
Lists all database connections configured in a specific environment.
Assigns or revokes a role's permission level on a database connection. • action="set" → PUT /rolepermissionlevel/ (requires PermissionLevelKey) • action="remove" → DELETE /rolepermissionlevel/ Use list_db_connection_permission_levels to discover valid levels.
Assigns or revokes a user's permission level on a database connection. • action="set" → PUT /userpermissionlevel/ (requires PermissionLevelKey) • action="remove" → DELETE /userpermissionlevel/ Use list_db_connection_permission_levels to discover valid levels.
Tags whatever is currently running in an environment as a NEW version of the application — useful for hotfix workflows or to capture exactly what is live in production. Requires the application to actually be running in the target environment. Returns the new ApplicationVersionKey on success.
Tests a database connection configuration without persisting it. Useful for validating credentials and reachability before calling create_db_connection.
Updates configuration values (site properties, timer schedules, etc.) for an application in a SPECIFIC environment. Workflow: (1) call get_application_configurations to discover Keys and current Values, (2) call update_application_configurations with the items to change. Only the items you list are modified; everything else stays untouched.
Updates an existing database connection. Provide the full configuration in Payload (LifeTime replaces the existing config wholesale).
Error handling in tool-helpers.ts returns LifeTimeAPIError.errors verbatim but does not provide recovery guidance. Descriptions lack 'If X fails, try Y' hints. Agents cannot self-correct from API errors.
Parameter descriptions lack format/constraint guidance. E.g., Color parameter states 'hex, e.g. #3A7BD5' but no regex pattern or validation rule. PermissionLevelKey described as 'e.g. Read, ReadWrite' but no enum constraint. LLMs may pass invalid values.