# Resources and prompts

Besides tools, Cademí MCP offers three resources, which give the assistant context to read, and three prompts, which give it a strategy for common investigations. Resources and prompts never change data.

## Resources

| URI | Type | Returns |
|---|---|---|
| `cademi://docs/terminology` | `text/markdown` | The Cademí vocabulary and the access reason codes. |
| `cademi://capabilities` | `application/json` | The tool catalog as metadata. |
| `cademi://instance/current` | `application/json` | The account and administrator of the connection. |

### `cademi://docs/terminology`

The Cademí vocabulary, so the assistant uses the right terms: account, student, administrator, product, module and lesson, enrollment, product access, release calendar, delivery, access schedule, and operation. Each term comes with its public ID prefix, such as `usr_` for students, `prd_` for products, and `enr_` for enrollments, and the resource ends with the reason codes of `student_access_context` ([Access reason codes](https://cademi.dev/mcp/tools.md#access-reason-codes)).

### `cademi://capabilities`

The tool catalog as JSON: the composite tools with their name, title, and permissions, and the tools per operation grouped by the first part of their name (`users`, `products`, `settings`), each with its name, title, permissions, and whether it is read-only. Reading this resource runs nothing and calls no API operation.

### `cademi://instance/current`

The account the connection works on and the administrator it acts as, with the same data as the `instance_overview` tool ([`instance_overview`](https://cademi.dev/mcp/tools.md#instance_overview)). Reading it calls the API, so it needs the `account.read` permission.

## Prompts

A prompt is a set of instructions the client gives the assistant, with the arguments you fill in. How you start a prompt depends on your client. Arguments that take a student accept a `usr_` ID, an e-mail address, or a name, and arguments that take a product accept a `prd_` ID or a name.

| Prompt | Arguments | What it does |
|---|---|---|
| `investigate-access-problem` | `student`, `product` | Finds out why a student cannot access a product, explains it, and proposes a fix. |
| `audit-student-experience` | `student` | Reviews a student's enrollments, access, and progress, and lists the problems. |
| `analyze-product-structure` | `product` | Reviews the structure of a product and how it is sold. |

### `investigate-access-problem`

Investigates why a student cannot access a product:

1. Calls `student_access_context` with the student and the product. If the reference is ambiguous, the assistant asks you which candidate you mean before it continues.
2. Explains the blocking reasons in plain language, citing the evidence: dates, enrollment status, and origin.
3. If a fix exists, proposes the action from the diagnosis, says what it changes, and asks for your confirmation. It changes nothing without it.
4. If the enrollment comes from a sale or a subscription, explains that the payment gateway manages it.

### `audit-student-experience`

Audits a student's experience:

1. Calls `student_context` and summarizes who the student is and what they are enrolled in.
2. For every product the student cannot access, and every enrollment that ends within 7 days, calls `student_access_context` and explains the reason.
3. Ends with a short list of issues, ordered by impact, and suggested next steps. It changes nothing.

### `analyze-product-structure`

Analyzes the structure of a product:

1. Calls `product_context` and `product_structure`.
2. Reports modules and lessons still in draft, modules without lessons, and whether the product is published and sold through at least one delivery.
3. Suggests improvements. It changes nothing without your confirmation.