MCP resources and prompts

Overview

• Resources expose readable context through identified locations, such as policy documents.
• Prompts expose reusable task templates and arguments.
• Tools perform operations; resources provide content; prompts help compose a task.

Why this matters

Not every integration needs to be represented as a function call, and hosts may want discoverable source context or approved task templates.

An everyday example

A library has books to read, service tasks to request, and standard forms for common questions.

A technical example

A policy resource identifies a permitted policy version; a “summarize-policy” template defines how to request a summary.

How it works

1. Discover supported resources/prompts
2. Select or supply arguments
3. Fetch content/template
4. Verify permission and provenance
5. Compose model context.

Architecture and flow

Resource/template discovery → authorized read → context construction → model.

The insurance assistant example

An internal host loads a verified claims-process resource and applies a consistent explanation template.

When to use it

Reusable context and supported prompt-template workflows across hosts.

When to avoid it

Do not assume all hosts support or use every primitive, and do not allow resource content to become trusted system instructions.

Interview answer

“MCP tools act, resources provide context, and prompts provide reusable task templates. The host decides how to incorporate them safely.”

Benefits, trade-offs, and production considerations

• Resource URIs are identifiers, not necessarily public HTTP links.
• Validate supported schemes and access; avoid arbitrary URL fetches and sensitive context being included automatically.
• MCP resources.