Cloud DevOps MCP Server

Overview Schema Source Related Servers Discussions Admin

Review Cloud Identity Policy

review_cloud_identity_policy

Read-onlyIdempotent

Analyze raw AWS IAM, Azure RBAC, or GCP IAM policy JSON against provider-specific identity security packs. Review cross-cloud policy risks locally without calling cloud APIs or changing permissions.

Instructions

Apply deterministic provider-specific identity policy packs to raw AWS IAM, Azure RBAC or GCP IAM policy documents. Use this for cross-cloud identity security analysis; use review_iam_policy when assessing AWS IAM from mixed structured facts or policy JSON. It analyzes supplied policy JSON only and does not call cloud APIs or change permissions.

Input Schema

TableJSON Schema

Name	Required	Description
`provider`	Yes	Cloud provider whose identity policy syntax and policy pack should be applied.
`policyJson`	Yes	Raw provider policy document in JSON form; AWS IAM, Azure role definition/assignment data, or GCP IAM policy.
`policyName`	Yes	Name or identifier of the identity policy being reviewed.
`environment`	No	Optional deployment environment used to contextualize policy risk; defaults are handled by the policy pack.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`facts`	Yes
`findings`	Yes
`provider`	Yes
`riskLevel`	Yes
`riskScore`	Yes
`policyName`	Yes
`policyPack`	Yes
`environment`	Yes
`findingCount`	Yes
`highFindings`	Yes
`mediumFindings`	Yes
`recommendedGate`	Yes
`criticalFindings`	Yes
`assessmentConfidence`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.14.0Oct 3, 2026

addedInput schema / properties / environment / description

Added value: +"Optional deployment environment used to contextualize policy risk; defaults are handled by the policy pack."

addedInput schema / properties / policyJson / description

Added value: +"Raw provider policy document in JSON form; AWS IAM, Azure role definition/assignment data, or GCP IAM policy."

addedInput schema / properties / policyName / description

Added value: +"Name or identifier of the identity policy being reviewed."

addedInput schema / properties / provider / description

Added value: +"Cloud provider whose identity policy syntax and policy pack should be applied."

First observedv0.4.0Oct 1, 2026

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile carries less burden on the description. The description still adds valuable context by stating it analyzes supplied JSON only, does not call cloud APIs, and applies deterministic packs. It could say more about output/return behavior, but the added limits are meaningful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action, followed by routing guidance and a scope/limit statement. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the rich annotations cover the safety profile. Combined with the scope, routing, and no-API-call limits in the description, an agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3 and the schema does the heavy lifting. The description nonetheless maps the provider options to concrete policy syntaxes (AWS IAM, Azure RBAC, GCP IAM), reinforcing the provider enum's meaning beyond the schema field name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Apply deterministic provider-specific identity policy packs to raw AWS IAM, Azure RBAC or GCP IAM policy documents') and names the sibling it is distinct from. An agent can distinguish this from review_iam_policy without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the routing condition: use this for cross-cloud identity analysis, use review_iam_policy for AWS IAM from mixed structured facts or policy JSON. The alternative and its selecting condition are both named, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server