Source 936c2c52008e4b55b57f586a

---
name: lookup
description: Look up a service, team, or catalog entity in Rootly. Returns owner, on-call, recent reliability, dependencies, and any active incidents. Use when something breaks and the first question is who owns this.
argument-hint: [service-or-team-name]
disable-model-invocation: true
allowed-tools:
  - mcp__rootly__*
---

# Service / Team Lookup

You are answering "what is this thing and who owns it?" for a service, team, or catalog entity. The user may pass a partial or full name; do your best to resolve it.

## Workflow

### 1. Resolve the target

`$ARGUMENTS` is the search term. It might be:
- A service name (e.g. `payments-api`)
- A team name (e.g. `Platform`)
- A repository name
- A catalog entity slug

Strategy:
1. Try `mcp__rootly__listServices` with the term as a filter where supported. If the MCP tool offers a name/query filter, use it; otherwise fetch the first 50 and match client-side (case-insensitive substring).
2. If no service match, try `mcp__rootly__listTeams` similarly.
3. If still no match, try `mcp__rootly__listCatalogEntities` (across all catalogs).

Determine the **kind** of the resolved entity (`service`, `team`, or `catalog-entity`) — branch the rendering on that.

If multiple matches, list the top 5 and ask the user to disambiguate. Do not guess.

If no matches, say so and suggest the user check spelling or try a broader term.

### 2. Gather details — service path

If the resolved entity is a **service**:

1. Call `mcp__rootly__getService` for the full record. Capture: name, description, owning team, environment, slug, URL.
2. Call `mcp__rootly__getServiceUptimeChart` for the last 30 days (if the MCP supports a period parameter; otherwise default).
3. Call `mcp__rootly__listIncidents` with `filter_service_ids=<id>` and `filter_status=started` to surface active incidents on this service.
4. If the service references an owning team, call `mcp__rootly__getTeam` for the team's name and `mcp__rootly__get_oncall_schedule_summary` (or `mcp__rootly__get_oncall_handoff_summary`) for current on-call.
5. Optional: `mcp__rootly__listIncidents` filter by service in the last 90 days, page 1 only, to spot frequency.

### 3. Gather details — team path

If the resolved entity is a **team**:

1. Call `mcp__rootly__getTeam` for the record. Capture name, description, slug, members count if available.
2. Call `mcp__rootly__listServices` filtered by team to enumerate owned services.
3. Call `mcp__rootly__get_oncall_schedule_summary` for current on-call across the team.
4. Call `mcp__rootly__listIncidents` filtered by team and `status=started` for active incidents.

### 4. Gather details — catalog entity path

If the resolved entity is a **catalog entity**:

1. Call `mcp__rootly__getCatalogEntity` for the full record.
2. Note the catalog it belongs to (`mcp__rootly__getCatalog` if you need the catalog's name).
3. Surface any service/team references in the entity's properties.

### 5. Render

**Service rendering:**

```
## Service: [name]
*[slug] — [environment]*

### Ownership
- **Team**: [team name]
- **On-call right now**: [user name] (until [shift end])
- **Backup**: [backup name if available]

### Recent Reliability (30 days)
- Uptime: [percentage]
- Incidents: [count] ([critical: N, high: N, medium: N])
- MTTR: [duration]

### Active Incidents
[If any:]
- 🔴 [INC-XXXX] [title] — started [duration] ago
[If none:]
No active incidents.

### Description
[service description]
```

**Team rendering:**

```
## Team: [name]
*[slug] — [N members]*

### Owned Services ([N])
- [service-name] ([environment])
- [service-name] ([environment])
[max 10, then "+N more"]

### Currently On-Call
- [Schedule]: [user name] (until [time])

### Active Incidents ([N])
- 🔴 [INC-XXXX] [title]
[If none: "No active incidents."]
```

**Catalog entity rendering:**

```
## [Catalog] Entity: [name]
*[slug]*

### Properties
- [key]: [value]
- [key]: [value]

### Linked References
[Any service/team links found]
```

### 6. Read-only

This skill never mutates Rootly state.

### 7. Error handling

- If a downstream call fails (e.g. uptime chart API errors), render the rest of the data and add a one-line note: "*[Section]: not available — [error]*".
- Don't fail the whole response because one optional chart didn't load.
- If `getCurrentUser` is needed for context (and most cases don't require it), skip it.