Public assessment

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

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

What changed in the harness

Selection accuracy 94→98, token cost down 0%, unconfirmed writes 57%→62%.

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

17.1 / 30

17.1 out of 30

02Legibility

25.5 / 30

25.5 out of 30

03Economics

19.5 / 20

19.5 out of 20

04Discoverability

11.4 / 20

11.4 out of 20

Highest-impact fix

Estimated gain +13 points

Add explicit identity and permission preflight tools

Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.

Description evidence

Defects and rewrites.

7 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 the given directory for syntax and internal consistency, without accessing remote state or APIs. Returns any validation errors or warnings found, indicating whether the configuration is valid.
`tf_preflight`	no_return_description	Check which cloud providers are used in the Terraform workspace in the given directory and verify authentication status for each. Returns a per-provider report of detected credentials and auth readiness so credential issues can be caught before running plan or apply.
`tf_destroy`	no_return_description	Destroy all Terraform-managed infrastructure in the workspace. Call without confirmed=true on the first pass to return the destroy plan (what would be deleted); call with confirmed=true after explicit user approval to actually destroy the resources and return the result of the destroy operation. Irreversible — always show the plan first.
`tf_state`	no_return_description	Manage Terraform state in the workspace using the specified operation. Returns a list of resources in state (list), the attributes of the specified resource (show), or a confirmation of the state change (mv/rm).
`tf_resource`	no_return_description	Perform resource-level state operations (import, taint, untaint, refresh) on the specified resource address. Returns the outcome of the operation, such as a confirmation that the resource was brought under management, marked, unmarked, or that state was synced with real infrastructure.
`tf_init`	no_return_description	Initialize the Terraform working directory in the given path, downloading providers and modules and configuring the backend. Returns the initialization output so you can confirm providers and modules installed successfully before running plan or apply.
`tf_workspace`	no_return_description	Manage Terraform workspaces in the given directory using the specified operation. Returns a list of workspaces with the active one marked (list), the current workspace name (show), or a confirmation that the workspace was switched to or created (select/new).

Selection evidence

Confusable tool pairs.

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

Tool A	Tool B	Confidence	Why they collide
`tf_state`	`tf_workspace`	medium	Tasks phrased as 'show the current state/environment' are ambiguous: tf_state lists/shows resources in the state file while tf_workspace lists/shows environments; both take the same workdir/workspace inputs and expose list/show operations.
`tf_apply`	`tf_destroy`	medium	Cleanup tasks are ambiguous: 'remove infrastructure no longer in the config' is apply (its plan deletes out-of-config resources) while 'tear down everything' is destroy; both share the two-step confirmed flow and removal-of-infrastructure language.
`tf_apply`	`tf_resource`	medium	'Sync/reconcile my infrastructure' is ambiguous: tf_apply changes reality to match config, while tf_resource refresh changes state to match reality; both operate on real resources and infrastructure.
`tf_drift`	`tf_resource`	medium	Tasks about state-vs-reality are ambiguous: 'check for drift' maps to tf_drift (refresh-only plan) while 'sync state with what's deployed' maps to tf_resource refresh; both tools describe comparing/syncing state against the cloud.
`tf_validate`	`tf_plan`	medium	'Check my Terraform config before deploying' is ambiguous: tf_validate checks syntax/consistency while tf_plan shows the diff and also surfaces config errors; both are read-only pre-apply checks.
`tf_init`	`tf_workspace`	low	'Set up my workspace/project' could pick tf_init (downloads providers/modules) or tf_workspace new/select (creates/switches environments); the word 'workspace' matches one tool while 'set up' matches the other.
`tf_validate`	`tf_preflight`	low	A vague 'make sure everything checks out before I run' task could pick tf_validate (config syntax) or tf_preflight (provider auth); both are pre-flight check tools, though their descriptions point to distinct concerns.
`tf_plan`	`tf_preflight`	low	'Verify things are safe before I apply' could pick tf_plan (preview the diff) or tf_preflight (verify credentials/auth); both are read-only preparation steps run before apply.

Compare the field

One score is useful.
The evidence makes it actionable.

Back to the leaderboard