Loading ToolBench
An MCP server for Service Atlas, an internal service dependency registry backed by a graph database. Provides tools for service relationship analysis, risk assessment, and incident facilitation.
Service Atlas MCP has 7 tools with mostly adequate naming and descriptions, but significant gaps in input validation, output schema documentation, and error handling. Tool names follow verb_noun convention (get_*, search_*, find_*) which is positive. However, descriptions are brief (10-100 chars) and lack context about expected return formats, when to use each tool vs. alternatives, and error recovery paths. Input schemas are present but sparse, most parameters have minimal constraints (no enums, min/max, or regex patterns). Output schemas are not documented at all, callers must reverse-engineer what fields the API returns. Error handling is absent; no guidance for retryability or user-correctable errors. Tools lack annotations for destructive operations. Overall quality is below baseline for production agent use.
Creates a new debt item for a service
Creates a dependency connection between two entities. The service_id will depend on the dependency_id. The service_id is the consumer/caller that relies on dependency_id
Creates a new service
Search for a service by name
Returns all teams from the service atlas api
Gets a report of all services that have open debts and a count of the number of debts associated with them
Gets the debts for a specific service
Get a list of releases between two dates. Start date is inclusive, while the end date is an exclusive
No output schema documentation for any tool. LLMs cannot plan downstream tool calls or extract required data without knowing return structure. Critical for tool chaining (e.g., get_services_by_team returns service_id needed by get_debts_for_service, but this is not documented).
Input parameter descriptions are generic or missing context. E.g., get_releases accepts 'start' and 'end' with format YYYY-MM-DD, but no guidance on inclusive/exclusive semantics, timezone handling, or error cases (e.g., what if start > end?). Tool description mentions inclusive/exclusive but parameters do not.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 11 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Gets a list of services that this service depends on
Gets a list of services that depend on this service
Gets the risk report for a specific service
Gets the list of service types
Gets a paginated list of all service objects. The AI should get pages as needed. If a user mentions a specific service by name, it may be more efficient to use find_service_by_name.
Tool that returns a list of services for a team based on id
Gets a list of teams that own a service based on id
Returns the version of the Service Atlas MCP server
Retrieves the Service Atlas website URL from the environment.
NOTE TO AI: Removing a dependency is a sensitive action that is intentionally not available via this API. If the user requests this, call get_website to retrieve the URL, then inform the user they must remove dependencies manually through their Service Atlas web interface. If get_website returns an error, tell the user to visit their Service Atlas web interface without providing a specific URL.
Updates an existing service. It is recommended to get the service first and then update it, so all fields are updated.
No error handling or recovery guidance. Tools directly call api_caller.call_get() with requests.raise_for_status(), which throws raw HTTP exceptions. No try/catch, no categorization of retryable vs. fatal errors, no user-friendly error messages. An LLM encountering a 404 has no guidance on whether to retry, adjust parameters, or escalate.
No result limiting or pagination support. Tools return raw API responses without documented size caps. If /reports/services/debt returns 1000+ services, the entire list enters the LLM context window, wasting tokens and degrading reasoning. No limit, offset, or cursor parameters documented.
Parameter descriptions lack actionable constraints. E.g., 'query' in find_service_by_name has no guidance on min/max length, case sensitivity, partial matching, fuzzy vs. exact. 'service_id' and 'team_id' are described as 'guid', LLM must infer the exact format (UUID v4? lowercase? hyphens?). No enum, pattern, or format constraints visible in schema.
Tool descriptions under 100 characters often lack discovery hints. E.g., 'Get a list of teams that own a service based on id' does not explain when this tool is needed vs. alternatives, what happens if a service has no teams, or whether the returned team IDs can be used as input to other tools.
No tool annotations for read-only operations despite the code using readOnlyHint. While annotations are present in debt.py (readOnlyHint: True), they are not visible for all tools in schema input definitions. This prevents clients from understanding which tools are safe to call without side effects.