MCP server for OpsLevel that provides tools to query and interact with OpsLevel account data including teams, users, components, services, checks, campaigns, and infrastructure resources
Five tools with READ_ONLY operations. Tool naming is verb-based (teams, users, actions, filters, components) but lacks clarity on action type. Descriptions present but vary in quality: 'teams' and 'users' are generic; 'components' is exceptionally detailed with filter syntax examples. Input schemas visible for all tools, but most lack parameter descriptions. 'teams' has a searchTerm parameter with description; 'users', 'actions', 'filters' have empty input objects; 'components' has a filter parameter with extensive description. No output schemas documented. Error handling not visible in source. Composition is reasonable (each tool does one thing), but parameter naming could be more explicit (e.g., 'filter' is overloaded).
Get all the information about actions the user can run in the OpsLevel account
Filter and retrieve components in the OpsLevel catalog. Use as specific a filter as possible to narrow down results and avoid fetching a high number of components. Components represent services, APIs, libraries, and other software artifacts with metadata such as owner (Team), language, framework, maturity level, lifecycle stage, and tier. Lower tier_index indicates greater criticality. Lower level_index indicates lower maturity level (e.g. Bronze="0", Silver="1", Gold="2"). Use the 'filter' parameter to narrow down results. 'filter' "arg" must always be a string. For simple filters: { "key": "name", "type": "equals", "arg": "service-name" } For better precision, use composite filters: { "connective": "and", "predicates": [ { "key": "language", "type": "equals", "arg": "Python" }, { "key": "owner_id", "type": "equals", "arg": "gid://opslevel/Team/123" } ] } Common filter keys: name, language, framework, owner_id, tags, tier_index, lifecycle_index Common filter types: equals, contains, matches, exists, greater_than_or_equal_to For complete reference: - Keys: aliases, alert_status, component_type_id, creation_source, deploy_environment, domain_id, filter_id, framework, group_ids, language, level_index, lifecycle_index, name, owner_id, owner_ids, product, properties, property, relationship, repository_ids, system_id, tag, tags, tier_index - Types: belongs_to, contains, does_not_contain, does_not_equal, does_not_exist, does_not_match, does_not_match_regex, ends_with, equals, exists, greater_than_or_equal_to, less_than_or_equal_to, matches, matches_regex, satisfies_jq_expression
Get all the rubric filter names and which predicates they have for the OpsLevel account
users, actions, filters tools have empty input schemas (no parameters defined) but lack descriptions explaining what they return or when to use them. Generic descriptions like 'Get all the user names...' do not guide LLM selection.
No output schemas documented for any tool. LLMs cannot infer what fields to expect (e.g., does 'teams' return team_id, team_name, contact_methods as separate fields or nested?). This breaks downstream tool chaining.
components tool's 'filter' parameter accepts a complex object (simple or composite) but lacks type constraints. LLMs may pass invalid filter structures. No enum or pattern validation visible.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | <=2025-11-25 | v2 |
Get all team names, contact methods, and metadata for the OpsLevel account. Teams are owners of other objects in OpsLevel. Provide searchTerm when looking for a specific team by name.
Get all the user names, e-mail addresses and metadata for the OpsLevel account. Users are the people in OpsLevel. Only use this if you need to search all users.
Tool descriptions lack context on when to use each tool vs. alternatives. E.g., 'users' says 'Only use this if you need to search all users' but does not explain when that is necessary or how it differs from searching within teams.
No error handling guidance visible. If a filter is invalid or a search returns no results, LLMs have no recovery path documented.