Skip to main content
Glama
Mipiti
by Mipiti

Update Organization

update_organization

Update an organization's IEC 62443-4-1 maturity level and NIST CSF tier to reflect its security program targets. Admin-only action for adjusting compliance grades.

Instructions

Set per-organization level grades for IEC 62443-4-1 and NIST CSF.

Admin-only: the backend requires the caller to be an admin in the organization (or a superadmin). Non-admins will get a 403; do not invoke this tool unless you've verified admin role for the target org.

target_ml is the IEC 62443-4-1 Maturity Level the organization targets for its secure-development program (1-5). csf_tier is the NIST CSF Tier the organization targets for its cybersecurity risk-management posture (1-4).

Because None on the wire is indistinguishable from "field omitted", pass clear_target_ml=True or clear_csf_tier=True to explicitly reset a value to NULL. Omitting both the value and its clear_* flag leaves the existing server-side value untouched.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
org_idYesOrganization ID.
csf_tierNoNIST CSF Tier (1-4), or ``None`` to leave unchanged.
target_mlNoIEC 62443-4-1 Maturity Level (1-5), or ``None`` to leave unchanged.
clear_csf_tierNoExplicitly reset ``csf_tier`` to NULL.
server_versionYes
clear_target_mlNoExplicitly reset ``target_ml`` to NULL.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.62.2
  2. Removedv0.62.0
  3. First observedv0.57.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries full behavioral burden. It discloses the auth requirement, the 403 failure mode, the wire-level ambiguity of None, the clear_* flags for resetting values, and the behavior of leaving omitted values untouched. This goes well beyond what the schema alone conveys.

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?

The description is organized into four purposeful paragraphs: purpose, auth warning, parameter definitions, and None/clear semantics. No filler; each sentence explains a behavior or precondition the agent needs before calling.

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?

Very complete for a six-parameter tool: it covers auth, parameter ranges, reset semantics, and mutation behavior. It does not explain the required server_version parameter, which is also undocumented in the schema, so the definition has one minor blind spot.

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

Parameters5/5

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

The description adds ranges for target_ml (1-5) and csf_tier (1-4), explains the meaning of None versus omission, and clarifies the clear_* flags and their relationship to the value parameters. Schema coverage is high, but this description resolves semantics that the schema leaves ambiguous.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Set per-organization level grades for IEC 62443-4-1 and NIST CSF.' This clearly distinguishes it from the many compliance/control sibling tools and explains what 'update organization' means in this context.

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

Usage Guidelines5/5

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

It explicitly states the precondition: admin or superadmin required, and says not to invoke unless admin role is verified. It also implies the use case (updating org-level grades) and the when-not (non-admins will get a 403), so an agent can decide when this tool is appropriate.

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