EPMRPP-109097 || MCP. Tools. Add tool get defect types by project

[AleksandrParamonoff]

Implement tool for getting the ReportPortal Defect Types configuration for specific project.

[coderabbitai]

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

Summary by CodeRabbit

New Features

• Project Defect Types Retrieval: A new tool has been added to retrieve project-specific defect type configurations in JSON format, enhancing defect classification management and project analysis workflows.

Walkthrough

Adds a new MCP tool on TestItemResources named get_project_defect_types that calls ReportPortal's ProjectAPI.GetProject() to fetch and return a project's defect types as JSON; errors are mapped via extractResponseError. The tool is registered during server initialization.

Changes

Cohort / File(s)	Summary
New tool implementation internal/reportportal/items.go	Adds toolGetProjectDefectTypes() on TestItemResources; creates an MCP tool with id "get_project_defect_types", uses projectParameter for context, invokes lr.client.ProjectAPI.GetProject(ctx, project).Execute(), returns response body via readResponseBody on success or maps API errors via extractResponseError. Includes analytics wrapping.
Tool registration internal/reportportal/server.go	Registers testItems.toolGetProjectDefectTypes() with the MCP server during initialization (inserted after toolGetTestSuitesByFilter() registration).

Sequence Diagram(s)

sequenceDiagram
  participant User
  participant MCP as MCP Server
  participant TestItems as TestItemResources
  participant RP as ReportPortal Client
  User->>MCP: invoke get_project_defect_types (with project)
  MCP->>TestItems: call handler (toolGetProjectDefectTypes)
  TestItems->>RP: ProjectAPI.GetProject(project).Execute()
  alt success
    RP-->>TestItems: project data (JSON)
    TestItems-->>MCP: serialized response body
    MCP-->>User: 200 + JSON
  else error
    RP-->>TestItems: API error
    TestItems-->>MCP: mapped tool error
    MCP-->>User: error response
  end

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Pay attention to:
  • Correct use of ProjectAPI.GetProject and parameter passing.
  • Proper mapping of API errors via extractResponseError.
  • The analytics wrapper and event naming.
  • Registration order in server.go.

Poem

A small tool wakes to scan the land,
Calls ProjectAPI with a steady hand,
Returns defect types in tidy JSON,
Errors wrapped neat — no fuss, no tension,
Another helper humming in the band 🎶

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Description Check	❓ Inconclusive	No pull request description was provided by the author, making it impossible to evaluate whether descriptive information about the changeset was included. While the check is intentionally lenient and only aims to catch completely off-topic descriptions, the absence of any description leaves no content to assess against the changeset. This creates an ambiguous situation where the description cannot be verified as related to the changes, nor can it be classified as explicitly misleading or off-topic.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title "EPMRPP-109097 || MCP. Tools. Add tool get defect types by project" is directly and fully related to the changeset. The summary shows that a new public tool method toolGetProjectDefectTypes was added to fetch project defect types, and the title accurately reflects this main objective. The title includes the JIRA key for traceability, uses clear semantic language (MCP, Tools, Add), and provides a descriptive subject that aligns well with conventional commit practices.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch add-feature-get-defect-types

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull Request Overview

This PR adds a new MCP tool to retrieve defect types for a specific project in Report Portal. The implementation follows the existing pattern used for other test item-related tools.

Key changes:

• Added toolGetProjectDefectTypes() method to fetch defect types via the Project API
• Registered the new tool in the server initialization

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
internal/reportportal/server.go	Registers the new defect types tool in the server
internal/reportportal/items.go	Implements the tool to fetch project defect types via Project API

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coderabbitai]

Actionable comments posted: 2

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 433b5e1 and 1e540ba.

📒 Files selected for processing (2)

• internal/reportportal/items.go (1 hunks)
• internal/reportportal/server.go (1 hunks)

🧰 Additional context used

📓 Path-based instructions (2)

**/*.go

📄 CodeRabbit inference engine (README.md)

**/*.go: Go code must be formatted consistently; run the formatter (task fmt) on all Go source files
Go code should pass lint checks (task lint) before submission
When adding a new MCP tool, implement it as a method in the appropriate resource Go file returning (mcp.Tool, server.ToolHandlerFunc) and register it in NewServer via s.AddTool(...)

Files:

• internal/reportportal/items.go
• internal/reportportal/server.go

---

⚙️ CodeRabbit configuration file

Focus on Go best practices, error handling, concurrency safety, performance, and security. Check for proper resource cleanup and context handling.

Files:

• internal/reportportal/items.go
• internal/reportportal/server.go

internal/reportportal/**

⚙️ CodeRabbit configuration file

Pay special attention to API integration patterns, error handling, data validation, and MCP protocol compliance.

Files:

• internal/reportportal/items.go
• internal/reportportal/server.go

🔇 Additional comments (3)

internal/reportportal/items.go (2)

625-632: LGTM! Tool metadata follows established patterns.

The tool registration correctly uses the project parameter, includes a helpful description that guides users to the configuration/subtypes path, and integrates analytics appropriately.

---

633-636: LGTM! Proper parameter extraction and error handling.

The project parameter extraction follows the established pattern with appropriate error handling.

internal/reportportal/server.go (1)

66-66: LGTM! Proper tool registration.

The new tool is correctly registered following the established pattern, and its placement alongside other test item tools is appropriate.