> For the complete documentation index, see [llms.txt](https://mcp-test-kitchen-docs.cakewalk.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mcp-test-kitchen-docs.cakewalk.security/reference/resources-and-prompts.md).

# Resources and Prompts

Four catalog items advertised on every session, two valid and two that return schema invalid payloads.

Every session advertises the same two resources and two prompts, whichever scenario is active. They do not depend on your selection and you cannot turn them off.

They exist so you can exercise `resources/read` and `prompts/get` against a valid payload and an invalid one without disturbing whatever scenario you are testing.

***

## The Four Items

| Kind     | Name               | Lookup                     | Returns                               |
| -------- | ------------------ | -------------------------- | ------------------------------------- |
| Resource | `valid_resource`   | `test://resources/valid`   | Valid `text/plain` contents           |
| Resource | `invalid_resource` | `test://resources/invalid` | HTTP 200 with a schema invalid result |
| Prompt   | `valid_prompt`     | `valid_prompt`             | A valid user text message             |
| Prompt   | `invalid_prompt`   | `invalid_prompt`           | HTTP 200 with a schema invalid result |

`valid_prompt` takes an optional `topic` argument, which is folded into the returned message text. Omit it and the prompt uses a general label.

***

## What the Invalid Items Return

Both invalid items are intercepted before normal handling and answered with a well formed JSON-RPC envelope carrying a body that does not match the schema. The transport succeeds, the envelope is valid and the contents are wrong.

`invalid_resource` returns a content block with three problems at once.

```json
{
  "contents": [
    { "type": "blob", "blob": "not-valid-base64!!!", "mimeType": "not-a-mime-type" }
  ]
}
```

The blob is not valid base64, the MIME type is not a MIME type, and a `blob` content block is being returned for an item advertised as `text/plain`.

`invalid_prompt` returns a message missing its required field.

```json
{
  "messages": [
    { "content": { "type": "unknown_type", "text": "missing role field" } }
  ]
}
```

There is no `role`, and the content type is not one the specification defines.

***

## What to Look For in Your Client

These are deserialization tests, so the interesting behavior happens before your code sees anything.

* **Does your SDK throw, or hand you a partial object?** This decides whether you can catch the problem at all.
* **Does one bad item break the catalog?** Read `invalid_resource`, then read `valid_resource` in the same session. If the second fails, one malformed payload poisoned your client's state.
* **Does the error name the item?** A client that reports a parse failure without saying which URI produced it costs you the debugging session this server is meant to save.
* **Does a bad MIME type or a bad base64 blob get caught separately?** They fail for different reasons and a good error distinguishes them.

***

## In the Record

Resource and prompt requests land in the `resource_read` and `prompt_get` phases, and they are the only traffic that carries no `scenarioId`. The label on the card is the resource URI or the prompt name instead.

Filter by the Resources or Prompts category to see the discovery call and the read together.