Skip to main content
Glama

pbs_realm_openid_create

Create an OpenID authentication realm for user login with configurable issuer, client ID, scopes, and optional autocreate. Supports dry-run preview and client secret redaction.

Instructions

MUTATION (MEDIUM): create an OpenID authentication realm. Dry-run by default.

CLIENT-KEY REDACTION: client_key (the OAuth client secret), when supplied, is UNCONDITIONALLY redacted from the plan, detail, and audit ledger (only {"client-key": "[redacted]"} is recorded). confirm=True executes and returns a dict; synchronous, no UPID. NOTE: the browser-based auth-url/login handshake is out of scope for this plane (token-auth-shaped tools only) — see module docstring. Needs PROXIMO_PBS_* config.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
realmYesNew OpenID realm name.
promptNoOpenID prompt parameter.
scopesNoOpenID scope list, SPACE-separated (schema default: 'email profile').
commentNoOptional free-text comment.
confirmNoFalse (default) returns a dry-run PLAN preview; True executes the mutation.
defaultNoTrue to make this the default realm preselected on login.
audiencesNoOpenID audience list string, forwarded verbatim.
client_idYesOpenID client id.
acr_valuesNoOpenID ACR list string, forwarded verbatim.
autocreateNoAutomatically create PBS users on first login if they don't exist.
client_keyNoOpenID client secret; redacted from all plans/logs/ledger.
issuer_urlYesOpenID issuer URL.
proximo_targetNoWhich configured Proxmox target to run this call against — a target name from your multi-target config (a specific PVE/PBS/PMG/PDM box). Omit to use the single/default target from the environment; the selection applies only to this call.
username_claimNoClaim to use as the unique username; the identity provider must guarantee uniqueness.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

With no annotations, the description covers key behaviors: mutation with medium risk, dry-run ability, synchronous execution, no UPID, and client_key redaction from logs. It mentions config requirement. Could be improved by noting authentication/authorization needs or specific 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.

Conciseness5/5

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

The description is concise (four sentences) and well-structured with clear sections. Every sentence adds crucial information without redundancy. It is front-loaded with the essential purpose and mutation level.

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

Completeness5/5

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

Given the complexity (14 params, output schema present), the description covers all critical aspects: execution mode, secret handling, synchronous nature, and scope limitations. The param descriptions in the schema handle details, so the description's focus on behavior is appropriate and complete.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the dry-run/confirm pattern, the return type (dict), and the redaction behavior for client_key. This goes beyond the schema descriptions.

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 clearly states the action ('create an OpenID authentication realm') and the resource type. The tool name and description distinguish it from sibling tools like pbs_realm_openid_delete, get, list, update. The prefix 'MUTATION (MEDIUM)' further clarifies the operation type.

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?

The description provides clear guidance: dry-run by default, confirm=True to execute, and notes that browser-based auth is out of scope. It also refers to module docstring for broader context. However, it does not explicitly compare to alternative realm creation tools (e.g., LDAP) or state prerequisites beyond config.

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

Install Server

Other Tools

Latest Blog Posts

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/john-broadway/proximo'

If you have feedback or need assistance with the MCP directory API, please join our Discord server