Conversation
|
Any reason why you are keeping camel case for the tool names? Would't it be good to make the move to snake case? |
|
@hashneo - good point, maybe this restruct is good time to switch over. I've observed that when you change the tool names some AI hosts (copilot, claude, cursor) fumble and sometimes even errors out. however, if you restart them once or twice they're fine. maybe we need to let people know somehow |
hashneo
left a comment
hashneo
left a comment
There was a problem hiding this comment.
Nit: Some of the tools still have options on 1 line (resolve_provider_doc_id.go for example) which makes it a little difficult to read but overall nothing jumps out to me as problematic.
|
@hashneo - took your suggestion, will need an approval again :) |
|
LGTM! |
There was a problem hiding this comment.
Pull Request Overview
This PR implements a comprehensive restructuring of the Terraform MCP Server codebase to improve maintainability and organization. The primary purpose is to refactor the existing code structure by separating concerns into dedicated packages and updating API parameter naming conventions for consistency.
- Reorganizes code into specialized packages (
pkg/utils,pkg/client,pkg/tools,pkg/resources) - Updates API parameter names to use snake_case convention (e.g.,
providerName→provider_name) - Moves common functionality to shared utility and client packages
Reviewed Changes
Copilot reviewed 29 out of 30 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| pkg/utils/utils.go | New utility package with common functions extracted from tfregistry |
| pkg/client/registry.go | New client package for registry API communication |
| pkg/tools/*.go | Tool implementations moved from tfregistry to dedicated tools package |
| pkg/resources/*.go | Resource handling moved to dedicated resources package |
| e2e/payloads.go | Updates test payloads to use new snake_case parameter names |
2 participants
PCI review checklist
I have documented a clear reason for, and description of, the change I am making.
If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.
If applicable, I've documented the impact of any changes to security controls.
Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.