Concept: P-T-R Model

Prime Style MCP's architecture is built from three elements: Prompts, Tools, and Resources. We call this the P-T-R Model.

Understanding how these three elements work together is essential for grasping how MCP operates and getting the most out of its features.

A formal diagram will be added here.

As shown above, user requests are first interpreted by a Prompt, processed with the help of Tools and Resources, and then a final response is generated.

1. Prompts — The Command Center of Thinking

Role: Define and execute workflows

Prompts are the command center of the P-T-R Model. They interpret the request (goal) from the user and define the thinking process (workflow) to achieve that goal.

A prompt is a set of instructions to the LLM — detailing what steps to take, what to consider, and what format to produce.

Example: The refactoring_strategy prompt

1. Receives "codebase overview" and "problems" from the user.
2. Instructs the LLM to "consider design patterns such as the Strangler pattern and create a staged migration plan."
3. Requests output in the form of "a prioritized list of improvement items."

Prompts can also call other tools and resources.

2. Tools — The Execution Engine for Concrete Tasks

Role: Automate supplementary tasks

Tools are components that execute concrete processing to assist the thinking process of prompts. They automate repetitive tasks that would be tedious or error-prone for humans.

Tools can be called by prompts, or used directly by users.

Examples:

• code_analyzer tool: Calculates Cyclomatic Complexity of source code. Called internally by the quality_review prompt to objectively evaluate code complexity.
• linter_config_generator tool: Generates linter config files for a specified language. Used in the project_setup workflow.

Tools take on the concrete "work" so prompts can focus on abstract "thinking."

3. Resources — The Referenced Knowledge Base

Role: Provide expert knowledge and data

Resources are static knowledge bases that prompts and tools reference. They store best practices, design pattern catalogs, checklists, team rules, and other specialized information.

Resources are used to improve the quality and consistency of prompt responses.

Examples:

• design_patterns resource: A catalog of GoF design patterns with explanations. Referenced by the architecture_design prompt to suggest appropriate patterns.
• security_checklist resource: Security check items based on the OWASP Top 10. Referenced by the quality_review prompt for security-focused reviews.

Keeping resources separate allows knowledge updates (e.g., adding new design patterns) to happen independently from prompt logic.

P-T-R Model Interaction Flow

A typical interaction flow:

1. User sends a request to MCP. (e.g., "Review this PR")
2. Prompt (quality_review) receives the request and starts the workflow.
3. The prompt calls a Tool (code_analyzer) to perform a technical evaluation of the code.
4. The prompt then references a Resource (security_checklist) to retrieve security check items.
5. The prompt integrates results from steps 3 and 4, generates a final review comment draft, and returns it to the User.

In this way, the P-T-R Model clearly separates thinking (Prompts), work (Tools), and knowledge (Resources) — connecting them to build a flexible and powerful expert system.