PowerShell Exec MCP Server
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@PowerShell Exec MCP Servergenerate an Intune detection script for checking if a specific Windows update is installed"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
PowerShell Exec MCP Server
A secure Model Context Protocol (MCP) server that provides controlled PowerShell command execution capabilities through MCP tools. This server includes security features to prevent dangerous commands, provides timeouts for command execution, and specializes in enterprise script generation for Microsoft Intune and IBM BigFix management platforms.
Features
Secure PowerShell command execution
JSON-formatted output for structured data
System information retrieval
Service management and monitoring
Process monitoring and analysis
Event log access
PowerShell script generation
Template-based script generation
Dynamic script generation
Microsoft Intune detection and remediation script generation
IBM BigFix relevance and action script generation
Command timeout support
Blocking of dangerous commands
Non-interactive and profile-less execution
Async support
Type hints and input validation
Project Structure
mcp-powershell-exec/
├── mcp_powershell_exec/ # Main package directory
│ ├── __init__.py # Package initialization
│ ├── __main__.py # Entry point
│ ├── server.py # Server implementation
│ ├── templates/ # PowerShell script templates
│ │ ├── basic_script.ps1 # Basic script template
│ │ ├── system_inventory.ps1 # System inventory template
│ │ ├── intune_detection.ps1 # Intune detection script template
│ │ ├── intune_remediation.ps1 # Intune remediation script template
│ │ ├── bigfix_relevance.ps1 # BigFix relevance script template
│ │ └── bigfix_action.ps1 # BigFix action script template
│ └── py.typed # Type hints marker
├── pyproject.toml # Project metadata and dependencies
├── setup.py # Package installation
└── README.md # DocumentationInstallation
Installing via Smithery
To install PowerShell Exec Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @DynamicEndpoints/powershell-exec-mcp-server --client claudeManual Installation
Ensure you have Python 3.7+ installed
Install the package:
pip install .Or install in development mode:
pip install -e .Usage
Running the Server
You can run the server in several ways:
Using the MCP CLI:
mcp run mcp_powershell_execUsing Python module:
python -m mcp_powershell_execUsing the console script:
mcp-powershell-execFor development and testing:
mcp dev mcp_powershell_execInstalling in Claude Desktop
To install the server in Claude Desktop:
mcp install mcp_powershell_execAvailable Tools
run_powershell
The base tool for executing PowerShell commands securely with timeout support.
Parameters:
code(required): PowerShell code to executetimeout(optional): Command timeout in seconds (1-300, default 60)
Example:
result = await run_powershell(
code="Get-Process | Select-Object Name, Id, CPU",
timeout=30
)get_system_info
Retrieve system information using Get-ComputerInfo cmdlet.
Parameters:
properties(optional): List of ComputerInfo properties to retrievetimeout(optional): Command timeout in seconds (1-300, default 60)
Example:
result = await get_system_info(
properties=["OsName", "OsVersion", "OsArchitecture"]
)get_running_services
Get information about Windows services.
Parameters:
name(optional): Filter services by name (supports wildcards)status(optional): Filter by status (Running, Stopped, etc.)timeout(optional): Command timeout in seconds (1-300, default 60)
Example:
result = await get_running_services(
name="*sql*",
status="Running"
)get_processes
Monitor running processes with filtering and sorting capabilities.
Parameters:
name(optional): Filter processes by name (supports wildcards)top(optional): Limit to top N processessort_by(optional): Property to sort by (e.g., CPU, WorkingSet)timeout(optional): Command timeout in seconds (1-300, default 60)
Example:
result = await get_processes(
top=5,
sort_by="CPU"
)get_event_logs
Access Windows event logs with filtering capabilities.
Parameters:
logname(required): Name of the event log (System, Application, Security, etc.)newest(optional): Number of most recent events to retrieve (default 10)level(optional): Filter by event level (1: Critical, 2: Error, 3: Warning, 4: Information)timeout(optional): Command timeout in seconds (1-300, default 60)
Example:
result = await get_event_logs(
logname="System",
newest=5,
level=2 # Error events only
)generate_script_from_template
Generate PowerShell scripts using predefined templates.
Parameters:
template_name(required): Name of the template to use (without .ps1 extension)parameters(required): Dictionary of parameters to replace in the templateoutput_path(optional): Where to save the generated scripttimeout(optional): Command timeout in seconds (1-300, default 60)
Example:
result = await generate_script_from_template(
template_name="basic_script",
parameters={
"SYNOPSIS": "My Test Script",
"DESCRIPTION": "A test script generated from template",
"PARAM1_DESCRIPTION": "First parameter",
"PARAM2_DESCRIPTION": "Second parameter",
"PARAM1_MANDATORY": "true",
"PARAM2_MANDATORY": "false",
"PARAM1_DEFAULT": "",
"PARAM2_DEFAULT": "default_value",
"MAIN_CODE": "Write-Host 'Hello World!'"
},
output_path="test_script.ps1"
)generate_custom_script
Generate custom PowerShell scripts based on description.
Parameters:
description(required): Natural language description of what the script should doscript_type(required): Type of script to generate (file_ops, service_mgmt, etc.)parameters(optional): List of parameters the script should acceptinclude_logging(optional): Whether to include logging functions (default: true)include_error_handling(optional): Whether to include error handling (default: true)output_path(optional): Where to save the generated scripttimeout(optional): Command timeout in seconds (1-300, default 60)
Example:
result = await generate_custom_script(
description="Script to monitor CPU usage and log high utilization",
script_type="monitoring",
parameters=[
{
"name": "ThresholdPercent",
"type": "int",
"mandatory": "true",
"default": "90"
},
{
"name": "LogPath",
"type": "string",
"mandatory": "false",
"default": "cpu_usage.log"
}
],
output_path="monitor_cpu.ps1"
)generate_intune_detection_script
Generate Intune detection scripts with proper exit codes and logging.
Parameters:
description(required): What the script should detectdetection_logic(required): PowerShell code that performs the detectionoutput_path(optional): Where to save the scripttimeout(optional): Command timeout in seconds (1-300, default 60)
Example:
result = await generate_intune_detection_script(
description="Check if Chrome is installed with correct version",
detection_logic="""
$app = Get-ItemProperty HKLM:\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths\\chrome.exe
$version = (Get-Item $app.Path).VersionInfo.FileVersion
$compliant = [version]$version -ge [version]"100.0.0.0"
Complete-Detection -Compliant $compliant -Message "Chrome version: $version"
""",
output_path="detect_chrome.ps1"
)generate_intune_remediation_script
Generate Intune remediation scripts with system restore points and error handling.
Parameters:
description(required): What the script should remediateremediation_logic(required): PowerShell code that performs the remediationoutput_path(optional): Where to save the scripttimeout(optional): Command timeout in seconds (1-300, default 60)
Example:
result = await generate_intune_remediation_script(
description="Install or update Chrome browser",
remediation_logic="""
$installer = "C:\\Windows\\Temp\\ChromeSetup.exe"
Invoke-WebRequest -Uri "https://dl.google.com/chrome/install/latest/chrome_installer.exe" -OutFile $installer
Start-Process -FilePath $installer -Args "/silent /install" -Wait
Remove-Item $installer
Complete-Remediation -Success $true -Message "Chrome installation completed"
""",
output_path="remedy_chrome.ps1"
)generate_intune_script_pair
Generate both detection and remediation scripts as a matched pair.
Parameters:
description(required): What the scripts should detect and remediatedetection_logic(required): PowerShell code that performs the detectionremediation_logic(required): PowerShell code that performs the remediationoutput_dir(optional): Directory to save the scriptstimeout(optional): Command timeout in seconds (1-300, default 60)
Example Usage:
Software Installation Check:
result = await generate_intune_script_pair(
description="Manage Chrome browser installation and version",
detection_logic="""
$app = Get-ItemProperty HKLM:\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths\\chrome.exe
$version = (Get-Item $app.Path).VersionInfo.FileVersion
$compliant = [version]$version -ge [version]"100.0.0.0"
Complete-Detection -Compliant $compliant -Message "Chrome version: $version"
""",
remediation_logic="""
$installer = "C:\\Windows\\Temp\\ChromeSetup.exe"
Invoke-WebRequest -Uri "https://dl.google.com/chrome/install/latest/chrome_installer.exe" -OutFile $installer
Start-Process -FilePath $installer -Args "/silent /install" -Wait
Remove-Item $installer
Complete-Remediation -Success $true -Message "Chrome installation completed"
""",
output_dir="chrome_scripts"
)BitLocker Encryption:
result = await generate_intune_script_pair(
description="Check and enable BitLocker encryption on system drive",
detection_logic="""
$systemDrive = $env:SystemDrive
$bitlockerVolume = Get-BitLockerVolume -MountPoint $systemDrive
$compliant = $bitlockerVolume.ProtectionStatus -eq 'On'
Complete-Detection -Compliant $compliant -Message "BitLocker status: $($bitlockerVolume.ProtectionStatus)"
""",
remediation_logic="""
$systemDrive = $env:SystemDrive
Enable-BitLocker -MountPoint $systemDrive -TpmProtector -UsedSpaceOnly
Backup-BitLockerKeyProtector -MountPoint $systemDrive -KeyProtectorId $bitlockerVolume.KeyProtector[0].KeyProtectorId
Complete-Remediation -Success $true -Message "BitLocker enabled with TPM protection"
""",
output_dir="bitlocker_scripts"
)Windows Update Configuration:
result = await generate_intune_script_pair(
description="Check and configure Windows Update settings",
detection_logic="""
$wu = New-Object -ComObject Microsoft.Update.AutoUpdate
$settings = $wu.Settings
$compliant = ($settings.NotificationLevel -eq 4) -and ($settings.NoAutoRebootWithLoggedOnUsers -eq $true)
Complete-Detection -Compliant $compliant -Message "Windows Update settings status"
""",
remediation_logic="""
$wu = New-Object -ComObject Microsoft.Update.AutoUpdate
$settings = $wu.Settings
$settings.NotificationLevel = 4
$settings.NoAutoRebootWithLoggedOnUsers = $true
$settings.Save()
Complete-Remediation -Success $true -Message "Windows Update settings configured"
""",
output_dir="windows_update_scripts"
)Security Settings:
result = await generate_intune_script_pair(
description="Check and configure basic Windows security settings",
detection_logic="""
$firewall = Get-NetFirewallProfile
$uac = (Get-ItemProperty HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System).EnableLUA
$screenSaver = (Get-ItemProperty 'HKCU:\\Control Panel\\Desktop').ScreenSaveActive
$compliant = ($firewall.Enabled -contains $true) -and ($uac -eq 1) -and ($screenSaver -eq 1)
Complete-Detection -Compliant $compliant -Message "Security settings status"
""",
remediation_logic="""
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True
Set-ItemProperty -Path HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System -Name EnableLUA -Value 1
Set-ItemProperty -Path 'HKCU:\\Control Panel\\Desktop' -Name ScreenSaveActive -Value 1
Complete-Remediation -Success $true -Message "Security settings configured"
""",
output_dir="security_scripts"
)BigFix Script Generation Tools
generate_bigfix_relevance_script
Generate BigFix relevance scripts to determine if computers need action.
Parameters:
description(required): What the script should checkrelevance_logic(required): PowerShell code that determines relevanceoutput_path(optional): Where to save the scripttimeout(optional): Command timeout in seconds (1-300, default 60)
Example:
result = await generate_bigfix_relevance_script(
description="Check if Chrome needs updating to version 100.0.0.0",
relevance_logic="""
try {
$app = Get-ItemProperty "HKLM:\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths\\chrome.exe" -ErrorAction Stop
$version = (Get-Item $app.'(Default)').VersionInfo.FileVersion
$needsUpdate = [version]$version -lt [version]"100.0.0.0"
Complete-Relevance -Relevant $needsUpdate -Message "Chrome version: $version (Target: 100.0.0.0+)"
} catch {
Complete-Relevance -Relevant $true -Message "Chrome not found - installation needed"
}
""",
output_path="chrome_relevance.ps1"
)generate_bigfix_action_script
Generate BigFix action scripts to perform remediation or configuration changes.
Parameters:
description(required): What the script should accomplishaction_logic(required): PowerShell code that performs the actionoutput_path(optional): Where to save the scripttimeout(optional): Command timeout in seconds (1-300, default 60)
Example:
result = await generate_bigfix_action_script(
description="Install Chrome browser to latest version",
action_logic="""
try {
$installer = "$env:TEMP\\ChromeSetup.exe"
Write-BigFixLog "Downloading Chrome installer..."
Invoke-WebRequest -Uri "https://dl.google.com/chrome/install/latest/chrome_installer.exe" -OutFile $installer -UseBasicParsing
Write-BigFixLog "Installing Chrome silently..."
Start-Process -FilePath $installer -Args "/silent /install" -Wait
Remove-Item $installer -Force
Complete-Action -Result "Success" -Message "Chrome installation completed successfully"
} catch {
Complete-Action -Result "RetryableFailure" -Message "Chrome installation failed: $($_.Exception.Message)"
}
""",
output_path="chrome_action.ps1"
)generate_bigfix_script_pair
Generate both relevance and action scripts as a matched pair for BigFix fixlet deployment.
Parameters:
description(required): What the scripts should accomplishrelevance_logic(required): PowerShell code that determines relevanceaction_logic(required): PowerShell code that performs the actionoutput_dir(optional): Directory to save the scriptstimeout(optional): Command timeout in seconds (1-300, default 60)
Example Usage:
Chrome Browser Management:
result = await generate_bigfix_script_pair(
description="Manage Chrome browser installation with version 100.0.0.0 or higher",
relevance_logic="""
try {
$app = Get-ItemProperty "HKLM:\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths\\chrome.exe" -ErrorAction Stop
$version = (Get-Item $app.'(Default)').VersionInfo.FileVersion
$needsAction = [version]$version -lt [version]"100.0.0.0"
Complete-Relevance -Relevant $needsAction -Message "Chrome version: $version (Target: 100.0.0.0+)"
} catch {
Complete-Relevance -Relevant $true -Message "Chrome not found - installation needed"
}
""",
action_logic="""
try {
$installer = "$env:TEMP\\ChromeSetup.exe"
Write-BigFixLog "Downloading Chrome installer..."
Invoke-WebRequest -Uri "https://dl.google.com/chrome/install/latest/chrome_installer.exe" -OutFile $installer -UseBasicParsing
Write-BigFixLog "Installing Chrome silently..."
Start-Process -FilePath $installer -Args "/silent /install" -Wait
Remove-Item $installer -Force
Complete-Action -Result "Success" -Message "Chrome installation completed successfully"
} catch {
Complete-Action -Result "RetryableFailure" -Message "Chrome installation failed: $($_.Exception.Message)"
}
""",
output_dir="chrome_bigfix_scripts"
)Windows Update Configuration:
result = await generate_bigfix_script_pair(
description="Ensure Windows Update service is running and configured properly",
relevance_logic="""
$service = Get-Service -Name "wuauserv" -ErrorAction SilentlyContinue
$needsAction = ($service.Status -ne "Running") -or ($service.StartType -ne "Automatic")
Complete-Relevance -Relevant $needsAction -Message "Windows Update service status: $($service.Status), StartType: $($service.StartType)"
""",
action_logic="""
try {
Set-Service -Name "wuauserv" -StartupType Automatic
Start-Service -Name "wuauserv"
Complete-Action -Result "Success" -Message "Windows Update service configured and started"
} catch {
Complete-Action -Result "RetryableFailure" -Message "Failed to configure Windows Update service: $($_.Exception.Message)"
}
""",
output_dir="windows_update_bigfix_scripts"
)Security Settings Configuration:
result = await generate_bigfix_script_pair(
description="Ensure basic Windows security settings are properly configured",
relevance_logic="""
$firewall = Get-NetFirewallProfile
$uac = (Get-ItemProperty HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System).EnableLUA
$firewallOk = ($firewall | Where-Object { $_.Enabled -eq $false }).Count -eq 0
$needsAction = (-not $firewallOk) -or ($uac -ne 1)
Complete-Relevance -Relevant $needsAction -Message "Security settings check - Firewall OK: $firewallOk, UAC Enabled: $($uac -eq 1)"
""",
action_logic="""
try {
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True
Set-ItemProperty -Path HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System -Name EnableLUA -Value 1
Complete-Action -Result "Success" -Message "Security settings configured successfully"
} catch {
Complete-Action -Result "RetryableFailure" -Message "Failed to configure security settings: $($_.Exception.Message)"
}
""",
output_dir="security_bigfix_scripts"
)Security Features
The server implements several security measures:
Blocks dangerous commands like:
Recursive deletions
Drive formatting
System shutdown/restart
Service manipulation
User account manipulation
Dynamic code execution
Command timeout enforcement
Non-interactive mode to prevent hangs
No profile loading to ensure clean execution environment
JSON output formatting for consistent data structures
Input validation for all tool parameters
Development
The project uses modern Python packaging tools and includes full type hints support. To set up a development environment:
Clone the repository
Create a virtual environment:
python -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activateInstall development dependencies:
pip install -e .Contributing
Contributions are welcome! Please ensure any changes maintain the security standards of the server.
License
MIT License
Available Tools
14 toolsensure_directoryBInspect
Ensure directory exists and return absolute path.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool ensures directory existence and returns a path, but lacks details on permissions needed, whether it creates directories if missing, error conditions, or side effects. This is a significant gap for a tool that likely involves file system mutations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded in a single sentence, with no wasted words. It efficiently conveys the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (involving file system operations) and the presence of an output schema, the description is minimally adequate. It covers the basic purpose but lacks behavioral details that annotations would normally provide, leaving gaps in understanding how the tool behaves in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema, which has 0% coverage. It clarifies that the 'path' parameter is used to specify the directory to ensure, providing context not in the schema. With only one parameter, this is sufficient to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('ensure') and resource ('directory'), explaining it checks existence and returns an absolute path. However, it doesn't differentiate from sibling tools, which are unrelated to directory management, so the distinction isn't necessary here.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description implies it's for directory existence checks, but it doesn't mention prerequisites, error handling, or comparisons to other file system operations in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_bigfix_action_scriptAInspect
Generate a BigFix action script to perform remediation or configuration changes.
Creates a PowerShell action script that follows IBM BigFix best practices:
- Proper exit codes (0=success, 1=retryable failure, 2=non-retryable failure)
- BigFix client log integration for monitoring
- System restore point creation before changes
- Comprehensive error handling and logging
- Event log integration for troubleshooting
⚠️ IMPORTANT: For complete BigFix deployments, you need BOTH relevance and action scripts.
Consider using 'generate_bigfix_script_pair' instead to create both scripts together.
IBM BigFix References:
- Action Scripts: https://help.hcltechsw.com/bigfix/11.0/platform/Platform/Console/c_creating_action_scripts.html
- Exit Codes: https://help.hcltechsw.com/bigfix/11.0/platform/Platform/Console/c_action_script_exit_codes.html
- Best Practices: https://help.hcltechsw.com/bigfix/11.0/platform/Platform/Console/c_best_practices_for_creating_fixlets.html
- Client Logging: https://help.hcltechsw.com/bigfix/11.0/platform/Platform/Installation/c_bes_client_logging.html
Args:
description: Clear description of what the script should accomplish (e.g., 'Install Chrome browser', 'Configure Windows firewall')
action_logic: PowerShell code that performs the action. Use 'Complete-Action -Result "Success/RetryableFailure/NonRetryableFailure" -Message "details"' to indicate completion
output_path: Optional file path where the script will be saved. If not provided, returns script content
timeout: Command timeout in seconds (1-300, default 60)
Returns:
Generated script content or path where script was saved
Example:
Generate a script to install Chrome:
```
result = await generate_bigfix_action_script(
description="Install Chrome browser to latest version",
action_logic='''
try {
$installer = "$env:TEMP\ChromeSetup.exe"
Write-BigFixLog "Downloading Chrome installer..."
Invoke-WebRequest -Uri "https://dl.google.com/chrome/install/latest/chrome_installer.exe" -OutFile $installer -UseBasicParsing
Write-BigFixLog "Installing Chrome silently..."
Start-Process -FilePath $installer -Args "/silent /install" -Wait
Remove-Item $installer -Force
Complete-Action -Result "Success" -Message "Chrome installation completed successfully"
} catch {
Complete-Action -Result "RetryableFailure" -Message "Chrome installation failed: $($_.Exception.Message)"
}
''',
output_path="chrome_action.ps1"
)
```
Tips:
- Always use Complete-Action function to set proper exit codes
- Use "Success" for completed actions
- Use "RetryableFailure" for temporary issues (network, locks, etc.)
- Use "NonRetryableFailure" for permanent issues (unsupported OS, etc.)
- Test action logic in safe environments first
- Consider creating system restore points for major changes
- Use Write-BigFixLog for detailed logging and troubleshooting
- Make actions idempotent (safe to run multiple times)
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | ||
| action_logic | Yes | ||
| output_path | No | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job describing what the tool generates (PowerShell scripts with specific best practices like exit codes, logging, restore points) and includes important warnings about testing in safe environments and making actions idempotent. It doesn't mention rate limits or authentication needs, but covers most critical behavioral aspects for a script generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, best practices, warnings, references, args, returns, example, tips) and front-loads the most important information. While comprehensive, some sections like the detailed reference URLs could be trimmed for conciseness. Every sentence adds value, but the overall length is substantial for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of generating BigFix action scripts, the description provides exceptional completeness. It covers purpose, best practices, warnings, parameter semantics, return values, examples, and tips. With an output schema present, it doesn't need to explain return values in detail. The description addresses all aspects needed for an AI agent to correctly use this tool, including sibling tool differentiation and implementation guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed explanations for all 4 parameters. Each parameter is clearly documented in the Args section with examples and constraints (e.g., 'Clear description of what the script should accomplish', 'PowerShell code that performs the action', 'Optional file path', 'Command timeout in seconds (1-300, default 60)'). The example further illustrates parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a BigFix action script to perform remediation or configuration changes.' It specifies the technology (PowerShell), the platform (IBM BigFix), and distinguishes it from sibling tools by mentioning 'generate_bigfix_script_pair' as an alternative for complete deployments. The verb 'generate' and resource 'BigFix action script' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives. It states: 'For complete BigFix deployments, you need BOTH relevance and action scripts. Consider using 'generate_bigfix_script_pair' instead to create both scripts together.' This directly addresses when to choose this tool over its sibling, and the Tips section offers additional usage advice like testing in safe environments first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_bigfix_relevance_scriptAInspect
Generate a BigFix relevance script to determine if computers need action.
Creates a PowerShell relevance script that follows IBM BigFix best practices:
- Proper output format (TRUE/FALSE for BigFix consumption)
- BigFix client log integration for monitoring
- Event log integration for troubleshooting
- Comprehensive error handling and logging
- Fast execution optimized for frequent evaluations
💡 TIP: For complete BigFix deployments, you need BOTH relevance and action scripts.
Consider using 'generate_bigfix_script_pair' to create both scripts together with matching logic.
IBM BigFix References:
- Relevance Language Guide: https://help.hcltechsw.com/bigfix/11.0/relevance/Relevance/c_relevance_language.html
- Action Scripts: https://help.hcltechsw.com/bigfix/11.0/platform/Platform/Console/c_creating_action_scripts.html
- Best Practices: https://help.hcltechsw.com/bigfix/11.0/platform/Platform/Console/c_best_practices_for_creating_fixlets.html
- Client Logging: https://help.hcltechsw.com/bigfix/11.0/platform/Platform/Installation/c_bes_client_logging.html
Args:
description: Clear description of what the script should check (e.g., 'Check if Chrome needs updating', 'Verify Windows patches are current')
relevance_logic: PowerShell code that determines relevance. Use 'Complete-Relevance -Relevant $true/$false -Message "status"' to indicate result
output_path: Optional file path where the script will be saved. If not provided, returns script content
timeout: Command timeout in seconds (1-300, default 60)
Returns:
Generated script content or path where script was saved
Example:
Generate a script to check if Chrome needs updating:
```
result = await generate_bigfix_relevance_script(
description="Check if Chrome browser needs updating to version 100.0.0.0 or higher",
relevance_logic=''',
try {
$app = Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe" -ErrorAction Stop
$version = (Get-Item $app.'(Default)').VersionInfo.FileVersion
$needsUpdate = [version]$version -lt [version]"100.0.0.0"
Complete-Relevance -Relevant $needsUpdate -Message "Chrome version: $version (Target: 100.0.0.0+)"
} catch {
Complete-Relevance -Relevant $true -Message "Chrome not found or inaccessible - installation needed"
}
''',
output_path="chrome_relevance.ps1"
)
```
Tips:
- Keep relevance logic fast and efficient (evaluated frequently)
- Return TRUE when action is needed, FALSE when compliant
- Always use Complete-Relevance function for proper BigFix output format
- Use try-catch blocks for robust error handling
- Test relevance logic thoroughly across different environments
- Use Write-BigFixLog for detailed progress tracking
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | ||
| relevance_logic | Yes | ||
| output_path | No | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job describing what the tool creates (PowerShell relevance scripts following IBM BigFix best practices), including specific behavioral traits like proper output format, logging integration, error handling, and optimization for frequent evaluations. The only minor gap is it doesn't explicitly mention whether this is a read-only or write operation, though 'generate' implies creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized for a complex tool. It starts with the core purpose, then provides best practices, usage tips, parameter documentation, and a comprehensive example. While lengthy, every section adds value. The only minor deduction is that some information (like the IBM references) could potentially be trimmed without losing core functionality guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, 0% schema coverage, but with output schema), the description is remarkably complete. It covers purpose, usage guidelines, behavioral traits, parameter semantics, provides a detailed example, and includes practical tips. The output schema exists, so the description doesn't need to explain return values, and it adequately addresses all other aspects needed for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation. Each parameter (description, relevance_logic, output_path, timeout) is clearly explained with examples and usage guidance. The description adds substantial meaning beyond what the bare schema provides, including format requirements, default values, and practical examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a BigFix relevance script to determine if computers need action.' It specifies the verb ('generate'), resource ('BigFix relevance script'), and distinguishes from siblings like 'generate_bigfix_action_script' by focusing on relevance scripts specifically. The tip about needing both relevance and action scripts further clarifies its role in the ecosystem.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives. The tip states: 'For complete BigFix deployments, you need BOTH relevance and action scripts. Consider using 'generate_bigfix_script_pair' to create both scripts together with matching logic.' This clearly indicates when to use this tool (for relevance scripts only) versus when to use the sibling tool (for paired scripts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_bigfix_script_pairAInspect
Generate a complete pair of BigFix relevance and action scripts for deployment.
This is the RECOMMENDED tool for BigFix fixlet creation as it creates both required scripts:
- Relevance script: Determines which computers need the action (TRUE/FALSE output)
- Action script: Performs the necessary changes with proper error handling
Both scripts follow IBM BigFix best practices:
- Proper BigFix output formats and exit codes
- BigFix client log integration for centralized monitoring
- System restore points before changes (action only)
- Comprehensive error handling and logging
- Event log integration for troubleshooting
- No user interaction (silent execution required)
IBM BigFix References:
- Fixlet Development: https://help.hcltechsw.com/bigfix/11.0/platform/Platform/Console/c_creating_fixlets.html
- Relevance Language: https://help.hcltechsw.com/bigfix/11.0/relevance/Relevance/c_relevance_language.html
- Action Scripts: https://help.hcltechsw.com/bigfix/11.0/platform/Platform/Console/c_creating_action_scripts.html
- Best Practices: https://help.hcltechsw.com/bigfix/11.0/platform/Platform/Console/c_best_practices_for_creating_fixlets.html
- Testing Guidelines: https://help.hcltechsw.com/bigfix/11.0/platform/Platform/Console/c_testing_fixlets.html
Args:
description: Clear description of what the scripts should accomplish (e.g., 'Manage Chrome browser installation and updates')
relevance_logic: PowerShell code that determines if action is needed. Use 'Complete-Relevance -Relevant $true/$false -Message "status"' to indicate result
action_logic: PowerShell code that performs the remediation. Use 'Complete-Action -Result "Success/RetryableFailure/NonRetryableFailure" -Message "details"' to indicate completion
output_dir: Optional directory to save both scripts. If not provided, returns script content in response
timeout: Command timeout in seconds (1-300, default 60)
Returns:
Dictionary containing both scripts: {"relevance_script": "content/path", "action_script": "content/path"}
Example:
Generate scripts to manage Chrome browser installation:
```
result = await generate_bigfix_script_pair(
description="Manage Chrome browser installation with version 100.0.0.0 or higher",
relevance_logic=''',
try {
$app = Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe" -ErrorAction Stop
$version = (Get-Item $app.'(Default)').VersionInfo.FileVersion
$needsAction = [version]$version -lt [version]"100.0.0.0"
Complete-Relevance -Relevant $needsAction -Message "Chrome version: $version (Target: 100.0.0.0+)"
} catch {
Complete-Relevance -Relevant $true -Message "Chrome not found - installation needed"
}
''',
action_logic=''',
try {
$installer = "$env:TEMP\ChromeSetup.exe"
Write-BigFixLog "Downloading Chrome installer..."
Invoke-WebRequest -Uri "https://dl.google.com/chrome/install/latest/chrome_installer.exe" -OutFile $installer -UseBasicParsing
Write-BigFixLog "Installing Chrome silently..."
Start-Process -FilePath $installer -Args "/silent /install" -Wait
Remove-Item $installer -Force
Complete-Action -Result "Success" -Message "Chrome installation completed successfully"
} catch {
Complete-Action -Result "RetryableFailure" -Message "Chrome installation failed: $($_.Exception.Message)"
}
''',
output_dir="chrome_bigfix_scripts"
)
```
Tips:
- Always test both scripts in a controlled environment first
- Ensure relevance logic matches the conditions that action script addresses
- Use descriptive logging messages for easier troubleshooting
- Consider the scope and impact of actions (test groups first)
- Make sure relevance logic is efficient (evaluated frequently)
- Ensure action logic is idempotent (safe to run multiple times)
- Use Write-BigFixLog for detailed progress tracking
- Test across different OS versions and configurations
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | ||
| relevance_logic | Yes | ||
| action_logic | Yes | ||
| output_dir | No | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly describes behavioral traits: it generates scripts following IBM BigFix best practices (e.g., proper output formats, log integration, system restore points, error handling, silent execution), includes references for development, and provides detailed tips on testing, scoping, and implementation considerations. This goes well beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with purpose and guidelines, but it's overly long with extensive reference links, tips, and a verbose example. While informative, some sections (like the full list of references) could be condensed or moved elsewhere, as not every sentence earns its place for core tool understanding. The structure is logical but not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (generating deployment scripts with best practices), no annotations, and an output schema that documents the return format, the description is highly complete. It covers purpose, usage, behavioral details, parameter semantics, examples, and tips, providing all necessary context for an AI agent to correctly invoke and understand the tool's scope and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds significant meaning beyond the bare schema: it explains what each parameter represents (e.g., 'description: Clear description of what the scripts should accomplish'), provides formatting guidance (e.g., using specific functions like 'Complete-Relevance'), and includes an extensive example showing parameter usage. However, it doesn't explicitly detail all parameter constraints (e.g., timeout range 1-300 is mentioned but not emphasized).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a complete pair of BigFix relevance and action scripts for deployment.' It specifies the verb ('generate'), resource ('BigFix relevance and action scripts'), and distinguishes it from siblings by emphasizing it's the 'RECOMMENDED tool for BigFix fixlet creation' that creates both required scripts, unlike separate relevance or action script generators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'This is the RECOMMENDED tool for BigFix fixlet creation as it creates both required scripts.' It distinguishes from alternatives by implying that for BigFix fixlets, this integrated pair generation is preferred over using separate sibling tools like 'generate_bigfix_action_script' or 'generate_bigfix_relevance_script' individually.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_custom_scriptBInspect
Generate a custom PowerShell script based on description.
Args:
description: Natural language description of what the script should do
script_type: Type of script to generate (file_ops, service_mgmt, etc.)
parameters: List of parameters the script should accept
include_logging: Whether to include logging functions
include_error_handling: Whether to include error handling
output_path: Where to save the generated script (optional)
timeout: Command timeout in seconds (1-300, default 60)
Returns:
Generated script content or path where script was saved
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | ||
| script_type | Yes | ||
| parameters | No | ||
| include_logging | No | ||
| include_error_handling | No | ||
| output_path | No | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the tool 'generates' a script and optionally saves it, but doesn't disclose critical traits like whether it's read-only/destructive, authentication needs, rate limits, error behavior, or how it handles invalid inputs. For a generative tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a purpose statement followed by parameter explanations, but it's verbose with repetitive formatting. Sentences like 'Args:' and 'Returns:' are redundant with the schema. While informative, it could be more streamlined by focusing on value-added details rather than restating obvious parameter names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and an output schema (which covers return values), the description is moderately complete. It explains parameters but misses behavioral context (e.g., generation limits, error handling). The output schema reduces the need to detail returns, but the description should still address usage scenarios and constraints for a generative tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all 7 parameters with brief explanations (e.g., 'Natural language description of what the script should do'), adding meaningful context beyond the bare schema. However, it lacks details on 'script_type' values (e.g., what 'file_ops' entails) or 'parameters' structure, preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a custom PowerShell script based on description.' It specifies the verb ('generate'), resource ('custom PowerShell script'), and mechanism ('based on description'). However, it doesn't explicitly differentiate from sibling tools like 'generate_script_from_template' or 'run_powershell', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'generate_script_from_template' (for template-based generation) or 'run_powershell' (for executing scripts), nor does it specify prerequisites or exclusions. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_intune_remediation_scriptAInspect
Generate a Microsoft Intune remediation script with enterprise-grade features.
Creates a PowerShell remediation script that follows Microsoft Intune best practices:
- Proper exit codes (0=success, 1=failure, 2=error)
- Event log integration for monitoring and troubleshooting
- System restore point creation before making changes
- Comprehensive error handling and logging
- No user interaction (required for Intune deployment)
⚠️ IMPORTANT: For complete Intune compliance, you need BOTH detection and remediation scripts.
Consider using 'generate_intune_script_pair' instead to create both scripts together.
Microsoft References:
- Intune Remediation Scripts: https://docs.microsoft.com/en-us/mem/intune/fundamentals/remediations
- Best Practices: https://docs.microsoft.com/en-us/mem/intune/fundamentals/remediations-script-samples
- PowerShell Script Requirements: https://docs.microsoft.com/en-us/mem/intune/apps/intune-management-extension
- Exit Code Standards: https://docs.microsoft.com/en-us/mem/intune/apps/troubleshoot-mam-app-installation#exit-codes
Args:
description: Clear description of what the script should remediate (e.g., 'Install Chrome browser', 'Configure Windows firewall')
remediation_logic: PowerShell code that performs the remediation. Use 'Complete-Remediation -Success $true -Message "description"' to indicate completion
output_path: Optional file path where the script will be saved. If not provided, returns script content
timeout: Command timeout in seconds (1-300, default 60)
Returns:
Generated script content or path where script was saved
Example:
Generate a script to install Chrome:
```
result = await generate_intune_remediation_script(
description="Install Chrome browser to latest version",
remediation_logic='''
$installer = "$env:TEMP\ChromeSetup.exe"
Invoke-WebRequest -Uri "https://dl.google.com/chrome/install/latest/chrome_installer.exe" -OutFile $installer
Start-Process -FilePath $installer -Args "/silent /install" -Wait
Remove-Item $installer -Force
Complete-Remediation -Success $true -Message "Chrome installation completed successfully"
''',
output_path="remediate_chrome.ps1"
)
```
Tips:
- Always use Complete-Remediation function to set proper exit codes
- Test your remediation_logic in a safe environment first
- Consider creating a system restore point for major changes
- Use Write-IntuneLog for detailed logging and troubleshooting
- Ensure no user interaction is required (scripts run silently)
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | ||
| remediation_logic | Yes | ||
| output_path | No | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the script follows enterprise-grade practices (exit codes, event log integration, system restore points, error handling, no user interaction), runs silently, and includes timeout handling. It also mentions testing recommendations and references Microsoft documentation. However, it doesn't explicitly state potential side effects like system changes or permission requirements, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose and key features. It uses bullet points for best practices, includes important warnings and alternatives, provides parameter explanations, an example, and tips. While comprehensive, some sections (like the extensive Microsoft references list) could be trimmed without losing essential information, making it slightly verbose but still highly usable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (generating scripts with enterprise features), no annotations, and an output schema that only indicates return types, the description provides excellent contextual completeness. It covers purpose, usage guidelines, behavioral traits, parameter semantics, examples, and tips. The output schema handles return values, so the description appropriately focuses on other aspects, making it fully sufficient for an agent to understand and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must fully compensate. It provides detailed explanations for all parameters: 'description' clarifies it's for what the script remediates, 'remediation_logic' specifies PowerShell code with usage of 'Complete-Remediation', 'output_path' explains optional file saving, and 'timeout' defines command timeout range and default. The example further illustrates parameter usage, adding significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a Microsoft Intune remediation script with enterprise-grade features.' It specifies the verb ('Generate'), resource ('Microsoft Intune remediation script'), and distinguishes it from sibling tools like 'generate_intune_script_pair' by focusing on remediation-only scripts. The description explicitly mentions what the script does (follows best practices like exit codes, event log integration, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives. It states: '⚠️ IMPORTANT: For complete Intune compliance, you need BOTH detection and remediation scripts. Consider using 'generate_intune_script_pair' instead to create both scripts together.' This clearly indicates when to use this tool (for remediation-only scripts) and when to prefer an alternative (for paired scripts), helping the agent make informed decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_intune_script_pairAInspect
Generate a complete pair of Microsoft Intune detection and remediation scripts.
This is the RECOMMENDED tool for Intune compliance as it creates both required scripts:
- Detection script: Checks current system state and determines compliance
- Remediation script: Fixes non-compliant conditions with proper safeguards
Both scripts follow Microsoft Intune best practices:
- Proper exit codes (Detection: 0=compliant, 1=non-compliant, 2=error; Remediation: 0=success, 1=failure, 2=error)
- Event log integration for centralized monitoring
- System restore points before changes (remediation only)
- Comprehensive error handling and logging
- No user interaction (silent execution required)
Microsoft References:
- Intune Remediation Scripts Overview: https://docs.microsoft.com/en-us/mem/intune/fundamentals/remediations
- Script Deployment Best Practices: https://docs.microsoft.com/en-us/mem/intune/fundamentals/remediations-script-samples
- PowerShell Requirements: https://docs.microsoft.com/en-us/mem/intune/apps/intune-management-extension
- Exit Code Standards: https://docs.microsoft.com/en-us/mem/intune/apps/troubleshoot-mam-app-deployment
- Monitoring and Reporting: https://docs.microsoft.com/en-us/mem/intune/fundamentals/remediations-monitor
Args:
description: Clear description of what the scripts should detect and remediate (e.g., 'Ensure Chrome browser is installed with latest version')
detection_logic: PowerShell code that performs the compliance check. Use 'Complete-Detection -Compliant $true/$false -Message "status"' to indicate result
remediation_logic: PowerShell code that fixes non-compliant conditions. Use 'Complete-Remediation -Success $true/$false -Message "result"' to indicate completion
output_dir: Optional directory to save both scripts. If not provided, returns script content in response
timeout: Command timeout in seconds (1-300, default 60)
Returns:
Dictionary containing both scripts: {"detection_script": "content/path", "remediation_script": "content/path"}
Example:
Generate scripts to manage Chrome browser installation:
```
result = await generate_intune_script_pair(
description="Ensure Chrome browser is installed with version 100.0.0.0 or higher",
detection_logic='''
try {
$app = Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe" -ErrorAction Stop
$version = (Get-Item $app.'(Default)').VersionInfo.FileVersion
$compliant = [version]$version -ge [version]"100.0.0.0"
Complete-Detection -Compliant $compliant -Message "Chrome version: $version (Required: 100.0.0.0+)"
} catch {
Complete-Detection -Compliant $false -Message "Chrome not found or inaccessible"
}
''',
remediation_logic='''
try {
$installer = "$env:TEMP\ChromeSetup.exe"
Write-IntuneLog "Downloading Chrome installer..."
Invoke-WebRequest -Uri "https://dl.google.com/chrome/install/latest/chrome_installer.exe" -OutFile $installer -UseBasicParsing
Write-IntuneLog "Installing Chrome silently..."
Start-Process -FilePath $installer -Args "/silent /install" -Wait
Remove-Item $installer -Force
Complete-Remediation -Success $true -Message "Chrome installation completed successfully"
} catch {
Complete-Remediation -Success $false -Message "Chrome installation failed: $($_.Exception.Message)"
}
''',
output_dir="chrome_intune_scripts"
)
```
Tips:
- Always test both scripts in a controlled environment first
- Use descriptive logging messages for easier troubleshooting
- Consider the impact of remediation actions (e.g., system restarts, user disruption)
- Use Write-IntuneLog for detailed progress tracking
- Ensure detection logic is fast and efficient (runs frequently)
- Make remediation logic idempotent (safe to run multiple times)
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | ||
| detection_logic | Yes | ||
| remediation_logic | Yes | ||
| output_dir | No | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains what the tool does: generates scripts following best practices like proper exit codes, event log integration, system restore points, error handling, and silent execution. It also details the return format ('Dictionary containing both scripts'), timeout behavior, and output options, providing comprehensive behavioral context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose and key features. However, it includes extensive sections like Microsoft references and a detailed example that, while helpful, make it longer than necessary. Every sentence adds value, but some redundancy (e.g., repeating exit code details) slightly reduces conciseness. Overall, it's efficient but could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (generating paired scripts with best practices), no annotations, and an output schema that only specifies return structure, the description provides complete context. It covers purpose, usage, behavioral details, parameter semantics, examples, and tips, ensuring the agent has all necessary information to use the tool correctly without relying on external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It does so by clearly explaining each parameter: 'description' specifies what scripts should do, 'detection_logic' and 'remediation_logic' define PowerShell code with usage examples, 'output_dir' indicates optional saving, and 'timeout' sets command limits. The example illustrates parameter usage in context, adding significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a complete pair of Microsoft Intune detection and remediation scripts.' It specifies the verb ('generate') and resource ('pair of Microsoft Intune detection and remediation scripts'), and distinguishes it from siblings by emphasizing it's the 'RECOMMENDED tool for Intune compliance' and creates both required scripts, unlike tools like 'generate_intune_remediation_script' which might only handle one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'This is the RECOMMENDED tool for Intune compliance as it creates both required scripts.' It implicitly suggests alternatives by mentioning sibling tools like 'generate_intune_remediation_script' for cases where only remediation is needed. The 'Tips' section adds context on when to use it effectively, such as testing in controlled environments and considering remediation impacts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_script_from_templateBInspect
Generate a PowerShell script from a template.
Args:
template_name: Name of the template to use (without .ps1 extension)
parameters: Dictionary of parameters to replace in the template
output_path: Where to save the generated script (optional)
timeout: Command timeout in seconds (1-300, default 60)
Returns:
Generated script content or path where script was saved
| Name | Required | Description | Default |
|---|---|---|---|
| template_name | Yes | ||
| parameters | Yes | ||
| output_path | No | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool 'generates' a script and optionally saves it, implying a write operation, but doesn't disclose critical behaviors: whether it overwrites existing files, requires specific permissions, has side effects, or handles errors. The timeout parameter hints at execution constraints, but this isn't elaborated. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the first sentence states the purpose, followed by a bullet-like 'Args' and 'Returns' section. Every sentence adds value—no fluff or repetition. It efficiently covers key aspects in minimal space, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, mutation operation, no annotations) and the presence of an output schema (implied by 'Returns' statement), the description is moderately complete. It explains parameters well and hints at outputs, but lacks behavioral context (e.g., file handling, permissions) and usage guidelines relative to siblings. For a template-based script generator, this leaves gaps in operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant semantic value beyond the input schema, which has 0% description coverage. It explains each parameter concisely: 'template_name' (name without extension), 'parameters' (dictionary for replacement), 'output_path' (optional save location), and 'timeout' (range and default). This compensates fully for the schema's lack of descriptions, making parameters clear and actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a PowerShell script from a template.' It specifies the verb ('generate'), resource ('PowerShell script'), and mechanism ('from a template'). However, it doesn't explicitly differentiate from sibling tools like 'generate_custom_script' or 'run_powershell', which leaves room for confusion about when to choose this specific template-based approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for script generation (e.g., 'generate_custom_script', 'generate_bigfix_action_script') and execution (e.g., 'run_powershell'), there's no indication of context, prerequisites, or trade-offs. The user must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_event_logsBInspect
Get Windows event logs.
Args:
logname: Name of the event log (System, Application, Security, etc.)
newest: Number of most recent events to retrieve (default 10)
level: Filter by event level (1: Critical, 2: Error, 3: Warning, 4: Information)
timeout: Command timeout in seconds (1-300, default 60)
| Name | Required | Description | Default |
|---|---|---|---|
| logname | Yes | ||
| newest | No | ||
| level | No | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions a timeout parameter which hints at potential execution constraints, but doesn't describe what happens on timeout, error conditions, permission requirements, rate limits, or the format/structure of returned logs. The description states it 'gets' logs but doesn't clarify if this is a read-only operation or has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by well-organized parameter documentation. Each parameter explanation is concise yet informative. The formatting with 'Args:' header and bullet-like parameter explanations makes it scannable, though it could be slightly more polished in presentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (though not shown), the description doesn't need to explain return values. However, for a tool with 4 parameters, no annotations, and system-level access to event logs, the description should provide more behavioral context about permissions, error handling, and typical use cases. The parameter documentation is excellent, but overall context about the tool's operation is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It provides clear explanations for all 4 parameters: logname examples (System, Application, Security), newest default and meaning, level mapping (1: Critical, etc.), and timeout range with default. This fully compensates for the schema's lack of descriptions and provides essential semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get Windows event logs' specifies the verb (get) and resource (Windows event logs). It distinguishes from siblings like get_processes or get_system_info by focusing specifically on event logs. However, it doesn't explicitly differentiate from potential similar logging tools that might exist in other contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any prerequisites, dependencies, or specific use cases. While the sibling tools are mostly script generation or system monitoring tools, there's no explicit comparison or context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_processesAInspect
Get information about running processes.
Args:
name: Filter processes by name (supports wildcards)
top: Limit to top N processes
sort_by: Property to sort by (e.g., CPU, WorkingSet)
timeout: Command timeout in seconds (1-300, default 60)
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| top | No | ||
| sort_by | No | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what the tool does (get process information) and includes parameter details that hint at behavior (filtering, sorting, timeout). However, it lacks critical behavioral details: whether this requires admin privileges, what format the output returns, if it's read-only, potential side effects, or error conditions. The timeout parameter description adds some behavioral context but doesn't fully compensate for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. The first sentence states the purpose clearly, followed by a parameter section with concise explanations. Every sentence earns its place, though the formatting with 'Args:' and bullet-like structure could be slightly more polished for maximum clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and good parameter coverage in the description, the description is reasonably complete. It covers the tool's purpose and all parameters thoroughly. The main gap is lack of behavioral context (permissions, side effects) and usage guidance relative to siblings, but the output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It provides excellent parameter semantics: explains what each parameter does, includes examples (e.g., 'CPU, WorkingSet' for sort_by), specifies constraints ('1-300, default 60' for timeout), and mentions features like wildcard support. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get information about running processes.' This is a specific verb+resource combination that distinguishes it from sibling tools like get_event_logs or get_system_info. However, it doesn't explicitly differentiate from get_running_services, which might be a related sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like get_running_services or get_system_info, nor does it specify scenarios where this tool is preferred. The only implicit guidance is through parameter descriptions, but no explicit usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_running_servicesBInspect
Get information about running services.
Args:
name: Filter services by name (supports wildcards)
status: Filter by status (Running, Stopped, etc.)
timeout: Command timeout in seconds (1-300, default 60)
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| status | No | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions a timeout parameter but doesn't explain what happens on timeout, whether the tool requires admin privileges, if it's read-only, or what format the returned information takes. This leaves significant behavioral gaps for a tool that interacts with system services.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement followed by parameter details. Every sentence adds value, though the parameter explanations could be slightly more integrated into the flow rather than listed as bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and the description compensates well for the 0% schema coverage, the description is moderately complete. However, it lacks behavioral context like permission requirements or error handling, which is important for a system tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial value beyond the input schema, which has 0% description coverage. It explains that 'name' supports wildcards, 'status' accepts values like 'Running' and 'Stopped', and 'timeout' has a range and default, effectively documenting all three parameters that the schema leaves undescribed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get information') and resource ('running services'), making it immediately understandable. However, it doesn't differentiate this tool from its siblings like 'get_processes' or 'get_event_logs' beyond the resource type, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_processes' or 'get_event_logs', nor does it specify scenarios where this tool is preferred or excluded, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_system_infoBInspect
Get system information.
Args:
properties: List of ComputerInfo properties to retrieve (optional)
timeout: Command timeout in seconds (1-300, default 60)
| Name | Required | Description | Default |
|---|---|---|---|
| properties | No | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions a timeout parameter with constraints (1-300 seconds, default 60), which adds some behavioral context. However, it doesn't disclose important aspects like what permissions are required, whether this is a read-only operation, what happens if properties are invalid, or how the information is returned. For a system information tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that each serve a purpose: stating the tool's purpose, explaining the properties parameter, and explaining the timeout parameter. It's front-loaded with the core purpose and uses a clear Args: section. There's minimal waste, though the formatting could be slightly cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 2 parameters with 0% schema coverage, and no annotations, the description does an adequate job. It explains both parameters' semantics and constraints, which addresses the schema coverage gap. However, for a system information tool that likely requires specific permissions and has behavioral nuances, the description should provide more context about what 'system information' includes and any limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for both parameters beyond what the schema provides. For 'properties', it specifies they are 'ComputerInfo properties to retrieve' and clarifies they're optional. For 'timeout', it provides the valid range (1-300) and default value (60), which aren't in the schema. With 0% schema description coverage, the description effectively compensates by explaining both parameters' purposes and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Get system information' which is a specific verb+resource combination. It distinguishes itself from sibling tools like get_event_logs, get_processes, and get_running_services by focusing on general system information rather than specific subsystems. However, it doesn't specify what type of system information (hardware, OS, configuration) or what 'ComputerInfo properties' encompasses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to sibling tools like get_event_logs or get_processes, nor does it specify prerequisites or constraints. The agent must infer usage from the tool name alone without contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_powershellAInspect
Execute PowerShell commands securely.
Args:
code: PowerShell code to execute
timeout: Command timeout in seconds (1-300, default 60)
ctx: MCP context for logging and progress reporting
Returns:
Command output as string
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| timeout | No | ||
| ctx | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'securely' which hints at safety considerations, and describes the return value format. However, it doesn't address important behavioral aspects like error handling, permissions required, side effects, or what 'securely' specifically entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, Args, Returns), uses bullet-like formatting for parameters, and contains no redundant information. Every sentence serves a specific purpose in explaining the tool's functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (executing arbitrary PowerShell code) and no annotations, the description does well by documenting all parameters and the return format. However, it could provide more context about security implications, execution environment, or error scenarios to be fully complete for such a powerful tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides comprehensive parameter documentation in the 'Args' section, explaining each parameter's purpose and constraints (e.g., timeout range 1-300 with default 60). This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Execute') and resource ('PowerShell commands'), plus the qualifier 'securely' which distinguishes it from generic execution tools. It precisely communicates what the tool does without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (executing PowerShell code) but doesn't explicitly state when to use this tool versus its sibling 'run_powershell_with_progress'. It provides general guidance but lacks specific differentiation from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_powershell_with_progressBInspect
Execute PowerShell commands with detailed progress reporting.
Args:
code: PowerShell code to execute
timeout: Command timeout in seconds (1-300, default 60)
ctx: MCP context for logging and progress reporting
Returns:
Command output as string with execution details
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| timeout | No | ||
| ctx | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'detailed progress reporting' and 'execution details' in the returns, which adds some context beyond basic execution. However, it lacks critical information such as security implications, error handling, side effects, or performance characteristics for a tool that executes arbitrary PowerShell code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for Args and Returns. It's front-loaded with the core purpose, and each sentence adds value. The only minor inefficiency is the repetition of 'detailed progress reporting' in both the description and returns section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (executing arbitrary code) and the presence of an output schema, the description is moderately complete. It covers parameters well but lacks behavioral context about security, errors, and side effects. The output schema handles return values, so the description doesn't need to detail them further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for all three parameters beyond the schema's 0% coverage. It explains that 'code' is 'PowerShell code to execute', 'timeout' is 'Command timeout in seconds (1-300, default 60)', and 'ctx' is 'MCP context for logging and progress reporting'. This compensates well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute PowerShell commands with detailed progress reporting.' This specifies the verb ('execute'), resource ('PowerShell commands'), and a key feature ('detailed progress reporting'). It distinguishes from the sibling 'run_powershell' by emphasizing progress reporting, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose it over the sibling 'run_powershell' or other script-generation tools, nor does it specify prerequisites or appropriate contexts for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
14 tool updates
v1.0.0- Changed
ensure_directory1 field changed- added
Input schema / titleAdded value: +"ensure_directoryArguments"
- Changed
generate_bigfix_action_script1 field changed- added
Input schema / titleAdded value: +"generate_bigfix_action_scriptArguments"
- Changed
generate_bigfix_relevance_script1 field changed- added
Input schema / titleAdded value: +"generate_bigfix_relevance_scriptArguments"
- Changed
generate_bigfix_script_pair1 field changed- added
Input schema / titleAdded value: +"generate_bigfix_script_pairArguments"
- Changed
generate_custom_script1 field changed- added
Input schema / titleAdded value: +"generate_custom_scriptArguments"
- Changed
generate_intune_remediation_script1 field changed- added
Input schema / titleAdded value: +"generate_intune_remediation_scriptArguments"
- Changed
generate_intune_script_pair1 field changed- added
Input schema / titleAdded value: +"generate_intune_script_pairArguments"
- Changed
generate_script_from_template1 field changed- added
Input schema / titleAdded value: +"generate_script_from_templateArguments"
- Changed
get_event_logs1 field changed- added
Input schema / titleAdded value: +"get_event_logsArguments"
- Changed
get_processes1 field changed- added
Input schema / titleAdded value: +"get_processesArguments"
- Changed
get_running_services1 field changed- added
Input schema / titleAdded value: +"get_running_servicesArguments"
- Changed
get_system_info1 field changed- added
Input schema / titleAdded value: +"get_system_infoArguments"
- Changed
run_powershell2 fields changed- added
Input schema / $defsAdded value: +{ + "Context": { + "description": "Context object providing access to MCP capabilities.\n\nThis provides a cleaner interface to MCP's RequestContext functionality.\nIt gets injected into tool and resource functions that request it via type hints.\n\nTo use context in a tool function, add a parameter with the Context type annotation:\n\n```python\n@server.tool()\ndef my_tool(x: int, ctx: Context) -> str:\n # Log messages to the client\n ctx.info(f\"Processing {x}\")\n ctx.debug(\"Debug info\")\n ctx.warning(\"Warning message\")\n ctx.error(\"Error message\")\n\n # Report progress\n ctx.report_progress(50, 100)\n\n # Access resources\n data = ctx.read_resource(\"resource://data\")\n\n # Get request info\n request_id = ctx.request_id\n client_id = ctx.client_id\n\n return str(x)\n```\n\nThe context parameter name can be anything as long as it's annotated with Context.\nThe context is optional - tools that don't need it can omit the parameter.", + "properties": {}, + "title": "Context", + "type": "object" + } +} - added
Input schema / titleAdded value: +"run_powershellArguments"
- Changed
run_powershell_with_progress2 fields changed- added
Input schema / $defsAdded value: +{ + "Context": { + "description": "Context object providing access to MCP capabilities.\n\nThis provides a cleaner interface to MCP's RequestContext functionality.\nIt gets injected into tool and resource functions that request it via type hints.\n\nTo use context in a tool function, add a parameter with the Context type annotation:\n\n```python\n@server.tool()\ndef my_tool(x: int, ctx: Context) -> str:\n # Log messages to the client\n ctx.info(f\"Processing {x}\")\n ctx.debug(\"Debug info\")\n ctx.warning(\"Warning message\")\n ctx.error(\"Error message\")\n\n # Report progress\n ctx.report_progress(50, 100)\n\n # Access resources\n data = ctx.read_resource(\"resource://data\")\n\n # Get request info\n request_id = ctx.request_id\n client_id = ctx.client_id\n\n return str(x)\n```\n\nThe context parameter name can be anything as long as it's annotated with Context.\nThe context is optional - tools that don't need it can omit the parameter.", + "properties": {}, + "title": "Context", + "type": "object" + } +} - added
Input schema / titleAdded value: +"run_powershell_with_progressArguments"
14 tool updates
- First observed
ensure_directory - First observed
generate_bigfix_action_script - First observed
generate_bigfix_relevance_script - First observed
generate_bigfix_script_pair - First observed
generate_custom_script - First observed
generate_intune_remediation_script - First observed
generate_intune_script_pair - First observed
generate_script_from_template - First observed
get_event_logs - First observed
get_processes - First observed
get_running_services - First observed
get_system_info - First observed
run_powershell - First observed
run_powershell_with_progress
TDQS
The tool set has clear groupings but some overlap exists. The BigFix and Intune script generation tools have distinct purposes (relevance/detection vs action/remediation), but 'generate_custom_script' and 'generate_script_from_template' could be confused with each other and with the specialized script generators. The system monitoring tools (get_event_logs, get_processes, etc.) are clearly distinct from script generation tools.
Most tools follow a consistent verb_noun pattern with snake_case (e.g., generate_bigfix_action_script, get_event_logs, run_powershell). The main deviation is 'ensure_directory' which uses a different verb style than others, but overall the naming is predictable and readable across the set.
14 tools is reasonable for a PowerShell execution server with script generation and system monitoring capabilities. The count feels slightly high but justified by covering both BigFix and Intune ecosystems plus general PowerShell execution. Some tools like 'run_powershell' and 'run_powershell_with_progress' could potentially be consolidated.
The server provides good coverage for PowerShell script generation (BigFix, Intune, custom) and system monitoring. Minor gaps exist: there's no tool for managing scheduled tasks or registry operations which are common PowerShell domains, and the script generation tools focus heavily on enterprise deployment scenarios while lacking simpler one-off script creation options beyond 'generate_custom_script'.
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
*Updated June 17th 2025** Manage your Microsoft 365 services effortlessly. Create and manage distr…
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Remote MCP for Copilot CLI switch gate MCP, structured receipts, audit logs, and reviewer-ready evid
Remote MCP for 1,500+ APIs. Vault-managed credentials; OAuth or API key. Search, load, and execute.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DynamicEndpoints/PowerShell-Exec-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server