Skip to main content
Glama
Pappa

mcp-oidc-proxy

by Pappa

update_settings

Modify OIDC proxy settings—issuer, audience, token expiry, PKCE, login mode, and SAML options—to control authentication behavior and token issuance.

Instructions

Update NanoIDP settings (issuer, audience, token expiry, SAML options, etc.). hooks: and plugins: (#185) are YAML-only, like secret_key and require_ui_login: they are reported by get_settings but cannot be changed here, since a command editable through the surface it observes would be a remote-execution primitive.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
issuerNoOAuth2/OIDC issuer URL
audienceNoDefault token audience
login_modeNoInteractive login mode: 'password' (default) requires the configured password on /login, /authorize, /saml/sso and the device flow; 'persona' lists the configured users and logs in by selecting one, no password prompt. Opt-in, off by default - a local development/testing convenience, not an authentication mode for deployed environments. Orthogonal to 'security_profile' and to the OAuth password grant, which is unaffected either way.
require_pkceNoReject /authorize requests without a PKCE code_challenge (#47)
saml_sso_urlNoSAML SingleSignOnService location. Empty string clears it so it is derived again as <issuer>/saml/sso (#181)
saml_entity_idNoSAML IdP entityID. Empty string clears it so it is derived again from the effective issuer as <issuer>/saml (#181)
verbose_loggingNoInclude usernames/client_ids in log messages (dev convenience)
issuer_allowlistNoOrigins (e.g. 'http://localhost:8000') allowed to be reflected back by 'issuer_from_request'. Empty (default) allows any Host header. A non-matching Host falls back to the fixed 'issuer'.
saml_export_rolesNoEmit the user's roles as a SAML attribute (off by default)
saml_export_groupsNoEmit the user's groups as a SAML attribute (off by default)
issuer_from_requestNoDerive the issuer from each request's own Host header instead of the fixed 'issuer' (dev convenience for setups reachable under more than one hostname). MCP tools have no request of their own, so this only affects HTTP discovery/token/device-flow responses, never MCP ones.
saml_c14n_algorithmNoXML canonicalization algorithm: 'c14n' (1.0), 'c14n11' (1.1), or 'exc_c14n' (Exclusive 1.0)
saml_sign_responsesNoEnable/disable SAML response signing
strict_saml_bindingNoEnforce strict SAML binding compliance (reject GET with uncompressed data)
saml_roles_attr_nameNoSAML attribute name for the roles (default: 'roles')
saml_sp_certificatesNoPEM certificate files of SPs whose AuthnRequest signatures are accepted
token_expiry_minutesNoToken expiration in minutes
saml_groups_attr_nameNoSAML attribute name for the groups (default: 'groups')
refresh_token_rotationNoRotate refresh tokens: each refresh invalidates the consumed refresh token (#46)
issuer_from_proxy_headersNoTrust 'X-Forwarded-Proto'/'X-Forwarded-Host'/'X-Forwarded-For' from a single reverse-proxy hop in front of NanoIDP (applies werkzeug's ProxyFix). Only affects the 'issuer_from_request' derivation - and only when that toggle is also on; it always affects rate-limit client IP attribution regardless. Only enable this when NanoIDP is deployed directly behind exactly one trusted proxy - these headers are otherwise spoofable by any client. Takes effect on the next app restart, not the running process.
device_verification_base_urlNoFixed base URL for the device flow's verification_uri (e.g. 'https://idp.example.com'), used instead of the request-derived issuer so a backend/container caller's Host doesn't leak into a URL a human's browser can't reach. Only consulted when 'issuer_from_request' is on; empty string clears it back to following the request Host.
saml_want_authn_requests_signedNoRequire and verify AuthnRequest signatures, both bindings (#69)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses the YAML-only limitation and the remote-execution security reasoning, which is valuable behavioral context. However, it does not mention whether changes are persisted, require a restart, or return the updated settings—though some of that is covered per-parameter in the schema. It is transparent about what it cannot do, which is a strong point.

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 a single sentence with the main purpose front-loaded, followed by a focused clarification about exclusions. No wasted words; every part earns its place.

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?

For an update tool with 22 optional parameters and no output schema, the description is reasonably complete in scope and limitation. It does not describe return values or error handling, but given the schema's thorough parameter explanations and the clear purpose, it is adequate for an agent to invoke correctly. The YAML-only caveat is a critical piece that is present.

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?

The schema provides 100% coverage with detailed descriptions for all 22 parameters, including enums and examples. The tool description adds no additional parameter-specific meaning beyond the overall scope. Baseline 3 is appropriate since the schema does the heavy lifting.

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 verb 'Update' and the resource 'NanoIDP settings', listing example categories (issuer, audience, token expiry, SAML options). It also differentiates from the sibling get_settings by explicitly noting which settings are YAML-only and cannot be changed here, so an agent can distinguish the tool's scope.

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 explains what the tool can and cannot do, specifically excluding hooks/plugins/secret_key/require_ui_login and giving a security rationale. However, it does not explicitly contrast with siblings like save_config or reload_config, nor does it state prerequisites (e.g., 'use get_settings first to see current values'). The guidance is implicit rather than explicit.

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