Spring Explore

Preflight: Spring MCP

This skill is part of the Spring Agent Toolkit and is designed to work with the Spring MCP server (provided by the Amplicode IntelliJ plugin). Before doing anything else, check your tool list for any Spring MCP tool — they are exposed under the amplicode MCP server (e.g. get_project_summary, list_module_dependencies, get_entity_details); harnesses that flatten MCP tools into the tool list use the mcp__amplicode__ prefix on the same names.

• If at least one Amplicode tool is available — MCP is connected. Proceed with the skill below.
• If none are available — stop and invoke the `amplicode-install` skill (bundled with the Spring Agent Toolkit). It installs the Amplicode plugin and walks the user through the «Настроить Spring Agent» welcome-screen button + MCP-client restart. After it completes, the MCP tools become available — resume this skill.
• If amplicode-install is not registered in your skill list, tell the user (in their language): "This skill needs the Amplicode IntelliJ plugin and its MCP server. Install it from https://amplicode.ru/marketplace into IntelliJ IDEA Ultimate/Community or GigaIDE, open any project, click «Настроить Spring Agent» on the Amplicode welcome screen, then restart your MCP client."

---

Explore Application

Collects primary project context in steps 0–6. Execute steps sequentially — each one builds on the results of the previous.

Important: if context has already been collected in the current conversation, do not repeat the exploration — use what is already known.

---

Step 0 — Predict involvement from the user's request

Tell the user: Step 0/6: Analyzing request...

Do NOT call any tools in this step.

Read the user's request and reason about what the implementation likely involves. Without calling any tools, make educated guesses based on naming conventions, domain language, and typical Spring Boot patterns:

• Entities — what domain objects are likely involved? (e.g. "create order" → Order, OrderItem)
• Repositories — which repositories probably exist for those entities?
• Services — what service classes are likely needed?
• Controllers — what REST controllers probably handle this area?
• Other beans/components — mappers, validators, event listeners, configs, etc.
• Files — what non-Java files are likely relevant? (e.g. DB migration scripts, application.properties, Liquibase changelogs, HTML templates). Do not list Java classes here — they belong to the categories above.

Build a preliminary gap list containing only what is genuinely required:

### Predicted involvement:
- Entities: Order, OrderItem, Customer
- Repositories: OrderRepository, CustomerRepository
- Services: OrderService
- Controllers: OrderController
- Other: OrderMapper
- Files: src/main/resources/db/migration/V1__create_orders.sql, application.properties

This prediction drives steps 1–5 — skip anything irrelevant to the task.

---

Step 1 — Define exploration goal and select paths

Tell the user: Step 1/6: Selecting exploration paths...

Do NOT call any tools in this step.

Read the current conversation context — the user's request, any prior exploration results, remaining gaps — and formulate the key exploration goal in one sentence. Show it to the user:

### Exploration goal:
Understand the Order aggregate structure and verify what repositories and mappers already exist.

Using this goal, go through each exploration path below and explicitly decide: include or skip, with a one-line reason. Do this for every path — do not skip the evaluation itself.

Project structure

• Fetch project summary — include if the tech stack, Spring Boot version, or module structure are needed. Skip if the task is narrowly scoped to specific classes.
• Detect persistence stack — include if any entity-touching path below is selected AND the stack (JPA vs JDBC) is not yet known from the conversation. Call list_module_dependencies: dependency on spring-boot-starter-data-jpa / hibernate → JPA; spring-boot-starter-data-jdbc / spring-data-jdbc → JDBC; neither → no supported persistence layer, skip entity-touching paths.
• List domain entities — include ONLY if the domain area is completely unknown and you cannot predict which entities are involved. If entities are already named in the request or predictable from context — skip. Do NOT use to get entity structure or resolve FQNs.
• List REST endpoints — include only if you need to check what already exists to avoid duplication or understand conventions. Skip if the request fully defines all endpoints from scratch.

Domain model

• Get entity description — include if entity fields or annotations are needed. Apply only to predicted entities, not all entities. Route by stack: JPA → get_entity_details, see `references/entity-description.md`; JDBC → get_jdbc_entity_details, see `references/entity-description-jdbc.md`.
• Get deep model from entity — include if relationships across multiple entities need to be traversed (e.g. nested resources, cascades). JPA only — for JDBC get_jdbc_entity_details already returns the full owned-children tree (aggregates) and inverse links (referencedBy); use the DDD path below instead. See `references/deep-model-based-on-jpa.md`.
• Get DDD model from entity — include if aggregate boundaries matter (e.g. URL design, cascade planning, DTO shaping). JPA: follow `references/ddd-model-based-on-jpa.md`. JDBC: call get_jdbc_entity_details and read aggregateRootFqn, aggregates, referencedBy directly — Spring Data JDBC enforces aggregate boundaries at the framework level.

Persistence

• Get entity repositories — include if repositories for predicted entities are unknown or need to be verified. See `references/entity-repositories.md`.
• Get entity components — include if you need a full picture of all components (repositories, services, controllers) for an entity. See `references/entity-components.md`.

Services

• Get entity services — include if services for predicted entities are unknown or need to be verified. See `references/entity-services.md`.

Mappers

• Get entity mappers — include if the task involves DTOs and you need to know what mappers exist. See `references/entity-mappers.md`.

DTOs

• Get entity DTOs — include if you need to know what DTO classes already exist. See `references/entity-dtos.md`.

REST layer

• Get entity controllers — include if you need to find which controllers are associated with an entity. See `references/entity-controllers.md`.

Write out the evaluation explicitly, then produce the final plan from included paths only:

Example — for a request "Add a paginated endpoint returning all orders for a customer with order items and product names":

### Path evaluation:
- Fetch project summary: INCLUDE — need Spring Boot version and module structure
- Detect persistence stack: INCLUDE — entity-touching paths selected and stack unknown from conversation
- List domain entities: SKIP — Order, Customer, OrderItem, Product are predictable from the request
- List REST endpoints: INCLUDE — need to check if an orders endpoint already exists
- Get entity description: INCLUDE — need Order, OrderItem, Product fields for response DTO design
- Get deep model: SKIP — relationship structure is clear: Order → OrderItem → Product
- Get DDD model: SKIP — no cascade planning needed, just a read endpoint
- Get entity repositories: INCLUDE — need to verify OrderRepository exists and supports pagination
- Get entity components: SKIP — repositories are sufficient, no need for full component chain
- Get entity services: SKIP — no service layer changes expected
- Get entity mappers: INCLUDE — need to know if OrderMapper already exists before creating DTOs
- Get entity DTOs: INCLUDE — need to know if OrderDto already exists
- Get entity controllers: SKIP — will check via "List REST endpoints" instead

### Exploration plan:
1. Fetch project summary
2. Detect persistence stack
3. List REST endpoints (filter to order-related controllers)
4. Get entity description for Order, OrderItem, Product
5. Get entity repositories for Order
6. Get entity mappers for Order
7. Get entity DTOs for Order

---

Step 2 — Load references

Tell the user: Step 2/6: Loading relevant references...

Do NOT call any tools in this step.

Based on the exploration plan from step 1, load only the references needed for the selected paths that have not already been loaded in this conversation. After loading, proceed directly to step 3 — do NOT search files, glob, or explore the project structure manually. All project information must be obtained exclusively via MCP tools in steps 3–5.

If none of the paths require references — skip this step and proceed to step 3.

---

Step 3 — Build unified exploration plan

Tell the user: Step 3/6: Building exploration plan...

Do NOT call any tools in this step.

Using the selected paths from step 1 and the processes described in the loaded references, build a single unified numbered plan of MCP calls to execute in steps 4–5. Each item must be a concrete MCP tool call, not a category name.

### Unified exploration plan:
1. get_project_summary
2. list_project_endpoints
3. list_all_domain_entities (regexPattern=Owner) — resolve FQN
4. get_entity_details (Owner FQN)
5. get_entity_details (Pet FQN)
6. get_entity_details (Visit FQN)
7. list_entity_repositories (Owner FQN)
8. list_entity_repositories (Pet FQN)
9. list_entity_repositories (Visit FQN)

---

Step 4 — Execute exploration plan via subagent

Tell the user: Step 4/6: Executing exploration plan...

Spawn a subagent and pass it the following instructions:

Execute the exploration plan below by calling each MCP tool in order.
Use MCP tools directly (e.g. get_entity_details, list_entity_repositories).

Collect and return ALL results in full — do not summarize or truncate.

Secret redaction: if any returned value belongs to a key that looks like a credential
(`password`, `passwd`, `secret`, `token`, `api-key`, `apikey`, `access-key`, `private-key`,
`credentials`, `client-secret`, `auth`, or similar), replace only the value with `[REDACTED]`
and keep the key and surrounding structure intact. Never echo credential values verbatim.

Plan:
<paste the numbered plan from step 3 here>

Wait for the subagent to complete and collect all results before proceeding.

---

Step 5 — Build exploration report

Tell the user: Step 5/6: Building exploration report...

Do NOT call any tools in this step — reason only from subagent results.

Synthesize all findings collected across all exploration cycles into a single report. Include only what is genuinely valuable for the task — omit noise and obvious defaults.

Structure:

### Exploration Report

**Stack:** Java 21 · Spring Boot 3.x · Maven
**Persistence:** JPA   <!-- JPA · JDBC · none — required when any entity-touching path ran -->

**Domain model:**
- Order (id, status, totalAmount) → has many OrderItem → references Product
- Customer (id, name, email)

**Repositories:**
- OrderRepository — extends JpaRepository, supports pagination
- CustomerRepository — extends JpaRepository

**Services:**
- OrderService — handles order creation and status transitions

**Mappers:**
- OrderMapper (MapStruct) — maps Order ↔ OrderDto

**DTOs:**
- OrderDto, OrderItemDto — already exist

**REST API (relevant endpoints):**
- GET /orders — paginated list
- POST /orders — create order

**Notable findings:**
- SecurityConfig present — all endpoints require authentication
- No mapper for Customer — will need to create one

---

Step 5.5 — Formulate implicit assumptions

Tell the user: Step 5.5/6: Formulating implicit assumptions...

Do NOT call any tools in this step — reason only from subagent results and the user's request.

Based on the exploration report and the user's request, identify everything the user did not explicitly say but likely expects from the implementation. These are implicit assumptions — unstated requirements, conventions, and design decisions the user probably takes for granted.

Focus on:

• Behavioral expectations — e.g. "user probably expects soft delete, not hard delete", "pagination assumed to be offset-based"
• Security/access control — e.g. "endpoint likely should require authentication like all others in this project"
• Validation — e.g. "fields like email and price are likely expected to be validated"
• Error handling — e.g. "returning 404 on missing entity is likely expected, not 500"
• Conventions — e.g. "response format likely expected to match existing endpoints (camelCase, wrapped in data field)"
• Related side effects — e.g. "creating an order probably expected to update inventory or send a notification"
• DTO shape — e.g. "response probably expected to include nested items, not just IDs"

Output all assumptions explicitly so they can be validated or corrected:

### Implicit assumptions:
1. The new endpoint should require authentication — all existing endpoints use SecurityConfig with auth required.
2. Response format should match existing endpoints — camelCase JSON, no wrapper object.
3. Pagination is expected to be offset-based (Pageable) — consistent with other list endpoints.
4. Missing entity should return 404, not 500 — standard REST convention followed elsewhere.
5. Price field is expected to be validated as positive — consistent with other monetary fields in the domain.
6. OrderItem list in response should include product name and quantity — implied by "order details" framing.

If no implicit assumptions can be identified — state that explicitly:

### Implicit assumptions: none identified — the request is fully specified.

---

Step 6 — Decide on next cycle

Tell the user: Step 6/6: Evaluating next cycle...

Do NOT call any tools in this step — reason only from subagent results.

Predict the value of an additional cycle (0–100): how critical are the remaining gaps, and are they resolvable via MCP? Show score and reasoning:

### Additional cycle value: 87/100 → additional exploration cycle required.

Score > 80 — go to Step 1. Score ≤ 80 — stop.

DDD Aggregate Model Analyser (JPA)

This skill inspects JPA entity relationships and returns the domain model in DDD terms: which entities are aggregate roots, which are members, and the ownership chain from root to each member.

Prerequisite: the project must use JPA (@Entity, @OneToMany, @ManyToOne, etc.). For non-JPA persistence (Spring Data JDBC, MongoDB, R2DBC, etc.) this skill does not apply — aggregate boundaries must be determined by other means.

The output can be used wherever aggregate boundaries matter: designing REST URLs, shaping DTOs, planning cascade strategies, writing queries, or simply understanding the domain model.

---

Step 0 — Resolve entity FQN (if unknown)

If you only know the simple class name (e.g. Owner) but not the fully qualified name, resolve it first:

• Call list_all_domain_entities via MCP with regexPattern=<SimpleName> to find the FQN.

list_all_domain_entities projectPath=<PATH> regexPattern=Owner

Use the qualifiedName from the result in all subsequent steps. Skip this step if the FQN is already known.

---

Step 1 — Collect entity details

For each entity relevant to the task, call get_entity_details (MCP tool) and collect the relationships array. You need these fields per relationship:

• cascadeTypes — list of cascade operations declared on the association
• fetchType — LAZY or EAGER
• targetEntity — the class on the other end of the relationship

For each entity relevant to the task:

• Call list_all_domain_entities via MCP to find entity qualified names (filter with regexPattern if needed).
• Call get_entity_details via MCP to get its relationships array with cascadeTypes, fetchType, and targetEntity.
• Repeat get_entity_details for each related entity that appears in the relationships.

---

Step 2 — Classify each relationship

For every relationship found in step 1, apply this rule:

The rule reflects DDD aggregate semantics: a member entity cannot exist or be accessed meaningfully without its root. cascade=ALL means the root controls creation and deletion (the clearest signal). EAGER without cascade means the root always loads it — tight enough coupling to treat it as a member.

@ManyToMany without cascade=ALL is almost always an independent root — the junction is just a cross-reference, not ownership.

---

Step 3 — Build the aggregate tree

Starting from each entity that is referenced by no other entity as a member, mark it as an aggregate root. Then walk its relationships transitively: members of members are also members of the same root.

Build a tree using the output format defined below. At this step, cross-refs are not yet marked — just establish roots and members:

Owner     [root]
  Pet     [member]
    Visit [member]

Vet       [root]   ← Specialty is @ManyToMany without cascade=ALL → independent root, not a member

Specialty [root]
PetType   [root]

---

Step 4 — Classify cross-aggregate references

Any relationship that crosses aggregate boundaries (i.e. the target is an independent root) is a cross-aggregate reference. Add → ref: lines to the tree from step 3:

Owner                  [root]
  Pet                  [member]
    → ref: PetType     [independent root, DTO: typeId]
    Visit              [member]

Cross-aggregate references matter for consumers of this output:

• In DTOs: carry only the ID of the referenced root, never the full nested object
• In cascades: do not cascade across aggregate boundaries

---

Output format

Return a single aggregate tree. Each aggregate root is a top-level entry; its members are indented beneath it. Cross-aggregate references are shown inline with → ref:.

Owner                          [root]
  Pet                          [member]
    → ref: PetType             [independent root, DTO: typeId]
    Visit                      [member]

Vet                            [root]
  → ref: Specialty             [independent root, @ManyToMany, DTO: specialtyIds[]]

Specialty                      [root]
PetType                        [root]

One tree — no separate lists. Everything visible at a glance:

• indentation = ownership depth
• [root] = independent aggregate root
• [member] = owned by the parent above
• → ref: = cross-aggregate reference (carry ID only in DTOs)

---

Common mistakes to avoid

Mistake: treating a @ManyToMany target as a member Vet.specialties is @ManyToMany — no cascade=ALL. Specialty is an independent root, not a member of Vet.

Mistake: promoting a cascade=ALL child to its own root Pet.visits is @OneToMany(cascade=ALL) — Visit is a member of Owner (via Pet), not an independent root.

Mistake: treating LAZY fetch without cascade as independent Check cascade first. If cascade=ALL is present, the entity is a member regardless of fetch type.

Deep Domain Model (JPA)

Traverses JPA entity relationships to a given depth and returns the domain model structure: entity names, fields, and how they relate to each other.

Prerequisite: the project must use JPA (@Entity, @OneToMany, @ManyToOne, etc.).

Use this reference when you need to understand the shape of the domain model beyond a flat list of entities — for example, to know which fields an entity has, what it references, and how deep the graph goes.

---

Step 0 — Resolve entity FQN (if unknown)

If you only know the simple class name (e.g. Order) but not the fully qualified name, resolve it first:

• Call list_all_domain_entities via MCP with regexPattern=<SimpleName> to find the FQN.

list_all_domain_entities projectPath=<PATH> regexPattern=Order

Use the qualifiedName from the result in all subsequent steps. Skip this step if the FQN is already known.

---

Step 1 — Collect entity details

Start from the entities identified in the main exploration (step 2 of the skill).

For each entity:

• Call get_entity_details via MCP to get its fields and relationships array.
• From relationships, collect all targetEntity values — these are the next level of entities.
• Repeat for each discovered entity until the desired depth is reached or no new entities appear.

Collect per relationship:

• relationshipType — @OneToMany, @ManyToOne, @ManyToMany, etc.
• targetEntity — the class on the other end
• fetchType — LAZY or EAGER
• cascadeTypes — list of cascade operations

---

Step 2 — Build the entity graph

Lay out all collected entities as a tree, indented by traversal depth. For each entity show its key fields and outgoing relationships.

Owner
  fields: firstName, lastName, address, telephone
  pets: Pet [@OneToMany, LAZY]
    fields: name, birthDate
    type: PetType [@ManyToOne, EAGER]
      fields: name
    visits: Visit [@OneToMany, cascade=ALL]
      fields: date, description

Vet
  fields: firstName, lastName
  specialties: Specialty [@ManyToMany]
    fields: name

Stop expanding a branch when:

• The target entity was already expanded at a higher level (avoid cycles)
• The desired depth limit is reached

---

Output format

Present the graph as an indented tree. For each entity show:

• Entity name
• Key scalar fields (skip technical fields like id, version, createdAt unless relevant)
• Each relationship on its own line: fieldName: TargetEntity [type, fetchType, cascade if any]

Keep it readable — the goal is a quick structural overview, not a full schema dump.

Entity Components

Finds all Spring components associated with a given JPA entity: repositories, services, and controllers.

Use this reference when you need a complete picture of the component chain for an entity before implementing or modifying functionality.

---

Step 0 — Resolve entity FQN (if unknown)

If you only know the simple class name, resolve the FQN first:

• Call list_all_domain_entities via MCP with regexPattern=<SimpleName>.

list_all_domain_entities projectPath=<PATH> regexPattern=Order

Use the qualifiedName from the result in all subsequent steps. Skip this step if the FQN is already known.

---

Step 1 — Find repositories

Follow `entity-repositories.md` to get all repositories for the entity.

---

Step 2 — Find all injecting beans

For each repository FQN from step 1:

• Call get_bean_injection_info via MCP to find all beans that inject it.

get_bean_injection_info projectPath=<PATH> beanClassQualifiedName=com.example.OrderRepository

For each injecting bean that is a service, repeat get_bean_injection_info to find beans that inject that service — go one level deeper until no new beans appear.

Collect all discovered beans across all levels.

---

Step 3 — Classify components

Classify each discovered bean:

---

Output format

**Order**
- Repository: OrderRepository (com.example.OrderRepository)
- Service:    OrderService (com.example.OrderService)
- Controller: OrderController (com.example.OrderController)

If a component type is absent, note it explicitly — e.g. "No service layer — repository injected directly into controller."

Entity Controllers

Finds REST controllers associated with a given JPA entity by tracing the dependency chain: entity → repositories → beans that inject those repositories → filter controllers.

---

Step 0 — Resolve entity FQN (if unknown)

If you only know the simple class name, resolve the FQN first:

• Call list_all_domain_entities via MCP with regexPattern=<SimpleName>.

list_all_domain_entities projectPath=<PATH> regexPattern=Order

Use the qualifiedName from the result in the next step. Skip this step if the FQN is already known.

---

Step 1 — Find repositories for the entity

• Call list_entity_repositories via MCP to get repositories linked to the entity.

list_entity_repositories projectPath=<PATH> entityFqn=com.example.Order

Collect the FQN of each repository found.

---

Step 2 — Find beans that inject those repositories

For each repository FQN from step 1:

• Call get_bean_injection_info via MCP to find all Spring beans that inject it.

get_bean_injection_info projectPath=<PATH> beanClassQualifiedName=com.example.OrderRepository

Collect all injecting beans from the result. These may be services, facades, or controllers.

---

Step 3 — Filter controllers

From the beans collected in step 2, keep only those that are REST controllers:

• Class is annotated with @RestController or @Controller
• Or class name ends with Controller

If injecting beans are services (not controllers), repeat step 2 for each service FQN to find beans that inject those services — go one level deeper until controllers are found or no more beans remain.

---

Output format

Order → OrderRepository → OrderService → OrderController
Order → OrderRepository → OrderController (direct injection)

If no controllers are found, note it explicitly — the entity may not be exposed via REST.

Entity Description (Spring Data JDBC)

Gets detailed information about one or more Spring Data JDBC entities: fields, annotations, aggregate structure, cross-aggregate references, and parent class.

---

Step 0 — Resolve entity FQN (if unknown)

If you only know the simple class name (e.g. Pet) but not the fully qualified name, resolve it first:

• Call list_all_domain_entities via MCP with regexPattern=<SimpleName>.

list_all_domain_entities projectPath=<PATH> regexPattern=Pet

Use the qualifiedName from the result in the next step. Skip this step if the FQN is already known.

---

Step 1 — Get entity details

For each entity, call get_jdbc_entity_details via MCP:

get_jdbc_entity_details projectPath=<PATH> entityFqn=com.example.Pet

Collect from the result:

• Fields: name, type, column name, nullable, annotations (@Id, @Column, @Embedded)
• Owned children: fields annotated @MappedCollection(idColumn=...) — part of the same aggregate
• Cross-aggregate links: fields typed AggregateReference<Target, IdType> — point at another aggregate root by id
• Aggregate metadata: aggregateRootFqn (null when the entity is the root), aggregates (recursive owned children tree), referencedBy (other aggregates linking here via AggregateReference)
• Parent class (if any)

Repeat for each entity that needs to be described.

---

Output format

**Pet**
- id: Long [@Id]
- name: String [@Column("name"), not null]
- birthDate: LocalDate [@Column("birth_date")]
- typeId: AggregateReference<PetType, Long>
- visits: Set<Visit> [@MappedCollection(idColumn="pet_id")]

Aggregate:
- root: true
- referencedBy: Owner.pets

Entity Description

Gets detailed information about one or more JPA entities: fields, annotations, relationships, and parent class.

---

Step 0 — Resolve entity FQN (if unknown)

If you only know the simple class name (e.g. Pet) but not the fully qualified name, resolve it first:

• Call list_all_domain_entities via MCP with regexPattern=<SimpleName>.

list_all_domain_entities projectPath=<PATH> regexPattern=Pet

Use the qualifiedName from the result in the next step. Skip this step if the FQN is already known.

---

Step 1 — Get entity details

For each entity, call get_entity_details via MCP:

get_entity_details projectPath=<PATH> entityFqn=com.example.Pet

Collect from the result:

• Fields: name, type, column name, nullable, annotations
• Relationships: type (@OneToMany, @ManyToOne, etc.), targetEntity, fetchType, cascadeTypes
• Parent class (if any)

Repeat for each entity that needs to be described.

---

Output format

**Pet**
- id: Long [@Id]
- name: String [@Column(name="name"), not null]
- birthDate: LocalDate [@Column(name="birth_date")]
- type: PetType [@ManyToOne, EAGER]
- visits: Set<Visit> [@OneToMany(cascade=ALL), LAZY]
- owner: Owner [@ManyToOne, LAZY]

Entity DTOs

Finds DTOs associated with a given JPA entity.

---

Step 0 — Resolve entity FQN (if unknown)

If you only know the simple class name, resolve the FQN first:

• Call list_all_domain_entities via MCP with regexPattern=<SimpleName>.

list_all_domain_entities projectPath=<PATH> regexPattern=Order

Use the qualifiedName from the result in the next step. Skip this step if the FQN is already known.

---

Step 1 — Find DTOs for the entity

• Call list_entity_dtos via MCP to get DTOs linked to the entity.

list_entity_dtos projectPath=<PATH> entityFqn=com.example.Order

Collect from the result:

• DTO class FQN
• Fields (if returned)

---

Output format

**Order**
- OrderDto — com.example.dto.OrderDto
- OrderCreateDto — com.example.dto.OrderCreateDto

If no DTOs are found, note it explicitly — the entity may be returned directly without a DTO layer.

Entity Mappers

Finds MapStruct mappers associated with a given JPA entity.

---

Step 0 — Resolve entity FQN (if unknown)

If you only know the simple class name, resolve the FQN first:

• Call list_all_domain_entities via MCP with regexPattern=<SimpleName>.

list_all_domain_entities projectPath=<PATH> regexPattern=Order

Use the qualifiedName from the result in the next step. Skip this step if the FQN is already known.

---

Step 1 — Find mappers for the entity

• Call list_entity_mappers via MCP to get mappers linked to the entity.

list_entity_mappers projectPath=<PATH> entityFqn=com.example.Order

Collect from the result:

• Mapper class FQN
• Mapped DTO classes (if returned)

---

Output format

**Order**
- OrderMapper — com.example.OrderMapper
  maps: Order ↔ OrderDto, Order ↔ OrderCreateDto

If no mappers are found, note it explicitly — the entity may use manual mapping or return raw entities.

Entity Repositories

Finds Spring Data repositories associated with a given JPA entity.

---

Steps

For each entity you need to find repositories for:

• Call list_entity_repositories via MCP to get all repositories linked to the entity.

From the result collect:

• Repository class FQN
• Supported query methods (if returned)

---

Output format

Owner
  OwnerRepository — ru.example.owner.OwnerRepository

Pet
  PetRepository — ru.example.owner.PetRepository

If no repository is found for an entity, note it as a gap — the entity may lack a repository or use a non-standard persistence approach.

Entity Services

Finds Spring services associated with a given JPA entity by tracing the dependency chain: entity → repositories → beans that inject those repositories → filter services.

---

Step 0 — Resolve entity FQN (if unknown)

If you only know the simple class name, resolve the FQN first:

• Call list_all_domain_entities via MCP with regexPattern=<SimpleName>.

list_all_domain_entities projectPath=<PATH> regexPattern=Order

Use the qualifiedName from the result in the next step. Skip this step if the FQN is already known.

---

Step 1 — Find repositories for the entity

• Call list_entity_repositories via MCP to get repositories linked to the entity.

list_entity_repositories projectPath=<PATH> entityFqn=com.example.Order

Collect the FQN of each repository found.

---

Step 2 — Find beans that inject those repositories

For each repository FQN from step 1:

• Call get_bean_injection_info via MCP to find all Spring beans that inject it.

get_bean_injection_info projectPath=<PATH> beanClassQualifiedName=com.example.OrderRepository

Collect all injecting beans from the result.

---

Step 3 — Filter services

From the beans collected in step 2, keep only those that are services:

• Class is annotated with @Service
• Or class name ends with Service, ServiceImpl, or Facade

Exclude controllers (@RestController, @Controller) and other non-service beans.

---

Output format

Order → OrderRepository → OrderService
Order → OrderRepository → OrderFacade

If no services are found, the entity is likely accessed directly from controllers — note this explicitly.