Skip to main content
Glama
Knuckles-Team

CISO Assistant MCP Server

Api policies sync to reference control create

ciso_assistant_api_policies_sync_to_reference_control_create

Create a sync mapping from policies to a reference control so applied controls and compliance policy links stay aligned.

Instructions

API endpoint that allows applied controls to be viewed or edited.

Input Schema

NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.6

TDQS

D1.8/5.0
Behavior2/5

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

Annotations declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the write/repeatability profile is already known; the description adds nothing about what gets created, what happens on re-sync (non-idempotent!), or what permissions are required. The 'viewed or edited' phrasing actively mischaracterizes a create/sync endpoint as a view/edit endpoint.

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

Conciseness3/5

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

It is a single short sentence with no padding, but that brevity comes from under-specification rather than economy; there is no front-loaded statement of the actual operation.

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

Completeness1/5

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

This is a non-idempotent, open-world create/sync mutation with no output schema and an undocumented id parameter. The description supplies none of the context an agent needs to invoke it safely, and the generic text hides the operation entirely.

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

Parameters2/5

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

One required parameter, 'id', with 0% schema description coverage. The description says nothing about whether this id refers to the policy being synced, the reference control, or the resulting applied control — which is the single most important ambiguity for this tool.

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

Purpose2/5

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

The sentence is generic DRF boilerplate ('allows ... to be viewed or edited') and never mentions the actual action, which is syncing a policy to a reference control. It also names the wrong resource ('applied controls'), so an agent reading only the description would not understand what the tool creates.

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

Usage Guidelines1/5

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

There is no when-to-use guidance, no prerequisites, and no mention of the obvious siblings that would be confused with it (policies_sync_to_reference_control vs reference_controls_sync_applied_controls_create, or policies_update). The agent has nothing to route on.

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