Skip to main content
Glama
RMITBLOG

Parallels RAS MCP Server

by RMITBLOG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Client Policies

ras_policies_list
Read-onlyIdempotent

List Parallels RAS client policies, including names, settings, and assignment status, to audit configurations or troubleshoot client behavior. Use fields to limit large responses.

Instructions

List all Parallels RAS client policies — policy names, settings, and assignment status. Client policies control user experience settings (display, audio, printing, device redirection). Use this to audit policy configuration or troubleshoot client behaviour. Policies can be deeply nested — use fields to project only top-level metadata when you don't need every rule.

Input Schema

NameRequiredDescriptionDefault
limitNoMax rows after filtering. Default 50, max 200. Prefer narrowing with `filter` over raising the limit.
fieldsNoTop-level keys to keep on each row. Unknown keys are dropped. Use this to shrink large responses to only the columns you need.
filterNoEquality filter on top-level fields (AND across keys). String values match case-insensitively.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.3.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / fields
      Added value: +{
+  "description": "Top-level keys to keep on each row. Unknown keys are dropped. Use this to shrink large responses to only the columns you need.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / filter
      Added value: +{
+  "additionalProperties": {
+    "type": [
+      "string",
+      "number",
+      "boolean"
+    ]
+  },
+  "description": "Equality filter on top-level fields (AND across keys). String values match case-insensitively.",
+  "type": "object"
+}
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Max rows after filtering. Default 50, max 200. Prefer narrowing with `filter` over raising the limit.",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}
  2. First observedv1.0.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive semantics, so the safety profile is covered. The description adds genuinely new behavioral context: policies are deeply nested, so `fields` should be used to project top-level metadata and avoid heavyweight responses. It does not discuss pagination or response size limits beyond that hint.

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

Conciseness5/5

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

Three sentences, all load-bearing: purpose first, use case second, the nesting/projection caveat last. No repetition of the schema, no filler, and the most actionable fact (deep nesting) is positioned where an agent will see it before building a query.

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

Completeness4/5

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

With no output schema and nested objects, the description usefully names what each row contains and warns about nesting depth. Combined with a fully documented input schema, an agent has enough to call it correctly, though it never states return volume or whether assigned/unassigned policies are both included.

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

Parameters3/5

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

Schema description coverage is 100% and the schema already documents limit, fields and filter in detail, including the filter semantics and max row count. The description only reiterates the `fields` projection idea (top-level metadata) and adds no syntax or format beyond what the schema states, so the baseline 3 applies.

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

Purpose4/5

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

The description gives a specific verb and resource ('List all Parallels RAS client policies') plus the payload it returns (names, settings, assignment status). It is clear, but it does not distinguish this tool from potentially overlapping siblings such as ras_site_get_printing or ras_site_get_connection_settings, which also govern user-experience settings like display, audio and printing.

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

Usage Guidelines4/5

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

It states concrete contexts for use ('audit policy configuration or troubleshoot client behaviour'), which is more than implied usage. It stops short of naming when not to use the tool or pointing at an alternative sibling, so it is clear but not exhaustive.

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

Deploy Server

Other Tools