Public assessment

RajeevSirohi/mcp-server-terraform (@rajsir/mcp-server-terraform)

rajsir-mcp-server-terraform · v0.1.0 · scanned Aug 2, 2026

What changed in the harness

Selection accuracy 98→100, token cost up 5%, unconfirmed writes 74%→68%.

Category breakdown

Where the score comes from.

Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.

01Safety

22.1 / 30

22.1 out of 30

02Legibility

25.6 / 30

25.6 out of 30

03Economics

19.5 / 20

19.5 out of 20

04Discoverability

11.9 / 20

11.9 out of 20

Highest-impact fix

Estimated gain +8 points

Make target tools discoverable on the first call

Clarify tool names, decision boundaries, and required argument schemas so an agent can choose and construct the target call without exploratory steps.

Description evidence

Defects and rewrites.

8 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.

Tool	Defect types	Suggested rewrite
`tf_validate`	no_return_description	Validate Terraform configuration files in a directory for syntax errors and internal consistency (e.g. type mismatches, invalid references). Does not access remote state or APIs. Returns a list of validation errors and warnings, or confirmation that the configuration is valid.
`tf_preflight`	no_return_description	Check which cloud providers are used in a Terraform workspace and verify authentication status for each. Call this before plan or apply to catch credential issues early. Returns, per detected provider, its name and whether valid credentials were found, plus any authentication errors encountered.
`tf_drift`	no_return_description	Detect infrastructure drift — resources that were changed outside of Terraform (e.g. manually in the cloud console). Runs a refresh-only plan and reports differences between state and reality. Read-only, makes no changes. Returns a human-readable diff listing resources and attributes that differ between recorded state and actual infrastructure.
`tf_destroy`	no_return_description	Destroy all Terraform-managed infrastructure in the workspace. TWO-STEP SAFETY FLOW: 1. Call without confirmed=true → returns the destroy plan (a list of resources that would be deleted) without making changes. 2. Call with confirmed=true after the user explicitly approves → destroys everything and returns a summary of destroyed resources. This is irreversible. Always show the plan and get explicit user approval first.
`tf_state`	no_return_description	Manage Terraform state. Supports the following operations: - list: returns the list of resource addresses currently in state - show: returns the full attribute set of the specified resource - mv: moves/renames a resource in state and returns confirmation of the new address (use with care) - rm: removes a resource from state without destroying it and returns confirmation (destructive to state tracking)
`tf_resource`	no_return_description	Resource-level state operations: - import: brings an existing cloud resource under Terraform management (requires address + id) and returns the imported resource's state - taint: marks a resource for recreation on next apply (requires address) and returns confirmation - untaint: removes the taint mark and returns confirmation - refresh: syncs state with real infrastructure, accepting drift into state, and returns the updated state summary
`tf_init`	no_return_description	Initialize a Terraform working directory by downloading providers and modules. Run this before plan or apply on a fresh workspace. Returns the initialization log, including provider/module versions installed and any errors encountered.
`tf_workspace`	no_return_description	Manage Terraform workspaces. Supports: - list: returns all workspace names and marks which one is active - show: returns the current workspace name - select: switches the active workspace and returns confirmation - new: creates a new workspace and returns confirmation

Selection evidence

Confusable tool pairs.

6 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.

Tool A	Tool B	Confidence	Why they collide
`tf_destroy`	`tf_state`	high	A vague instruction like 'remove this resource from my Terraform setup' is ambiguous between tf_destroy (irreversibly deletes the real cloud resource) and tf_state's 'rm' operation (only stops tracking it in state, leaving the resource running) — picking the wrong one has severe, opposite-direction consequences.
`tf_drift`	`tf_resource`	high	Tasks like 'sync my state with what's actually deployed' or 'reconcile drift' could map to either tf_drift (read-only report of differences) or tf_resource's 'refresh' operation (actually writes drift into state), which have very different safety implications despite similar goals.
`tf_validate`	`tf_preflight`	medium	Both are described as pre-run sanity checks ('check if my Terraform is ready to apply'); tf_validate checks config syntax while tf_preflight checks cloud credentials, and a generic 'make sure everything's OK before I apply' request doesn't clearly indicate which check is meant.
`tf_plan`	`tf_preflight`	medium	tf_preflight's description explicitly frames itself as a step to run 'before plan or apply', so a task like 'check everything is ready to go' could plausibly trigger either the auth-check tool or a dry-run plan instead.
`tf_validate`	`tf_plan`	medium	A task such as 'check if this Terraform config will work' is ambiguous between tf_validate (syntax/consistency check) and tf_plan (a diff showing what would actually change), since both are framed as safe pre-apply checks.
`tf_state`	`tf_workspace`	medium	Both tools support 'list' and 'show' operations and share the word 'state'/'current'; a request like 'show me the current state' could be misrouted to tf_workspace's 'show' (current workspace name) instead of tf_state's 'list' (resources in state), or vice versa.

Compare the field

One score is useful.
The evidence makes it actionable.

Back to the leaderboard