---
title: "List Installed On Self"
method: GET
path: "/api/skills/installed-on"
tags: ["skills"]
---

# List Installed On Self

`GET /api/skills/installed-on`

## Request

- Base URL: `https://app.thinqos.com` (the document declares no server; this is the origin it was published from)
- URL: `https://app.thinqos.com/api/skills/installed-on`
- Auth: none declared

Skills installed on a target, defaulting to the CALLER's own identity.

The two-parameter route below cannot answer "what skills do I have?",
because it requires the install_id you would be trying to discover. Over
the generic MCP verb tools that produced a genuine dead end: a caller asked
for its own installed skills, was told install_kind was required, supplied
it, and was then told install_id was required with no route from an agent
id to one. An agent that cannot enumerate its own skills cannot reason
about which to invoke, and an owner cannot audit whether the right skill
fired.

Mirrors ``_resolve_install_id`` (identity installs default to the caller)
and the ``/instances/installed-on/{identity_id}`` authority model in the
integrations API: self needs nothing, anyone else is owner-gated.

## Query parameters

- `install_kind` string
- `install_id` string, uuid, nullable

## Headers

- `x-impersonate-identity-id` string, nullable

## Response `200`

Successful Response

- InstalledSkillOut[]
  - `skill_id` string, uuid, required
  - `slug` string, required
  - `name` string, nullable
  - `description` string, required
  - `enabled` boolean, required
  - `available` boolean: Available in the identity's live skill registry; not runtime verification.
  - `content_vetted` boolean, required
  - `runtime_readiness` 'unverified'
  - `runtime_readiness_reason` string

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/thinqos/apis/thinqos-api.md) · [All operations](https://skmtc.dev/thinqos/apis/thinqos-api/llms.txt) · [OpenAPI document](https://skmtc.dev/thinqos/apis/thinqos-api/revisions/5387b4ded614?raw)