Skip to main content
Glama
Pappa

mcp-oidc-proxy

by Pappa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

generate_token

Generate an OAuth2 access token for a user to authenticate MCP clients, enabling access to protected tools. Supports scopes, extra claims, and expiration.

Instructions

Generate an OAuth2 access token for a user

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNoSpace-separated OAuth scopes (optional). Include 'openid' to also receive an ID Token; the scope is persisted in the refresh token so refreshing re-issues an ID Token (OIDC Core §12.2)
usernameYesUsername to generate token for
extra_claimsNoAdditional claims to include in the token
id_token_claimsNoClaim names to embed in the ID Token, mirroring the OIDC `claims` request parameter (§5.5). Requires an 'openid' scope. Resolved from the user (e.g. 'email', 'preferred_username', or a custom attribute); names nanoidp cannot supply are skipped.
userinfo_claimsNoClaim names /userinfo should return for this access token, mirroring the `userinfo` member of the OIDC `claims` request parameter (§5.5). Stamped on the access token as `req_userinfo_claims` and honoured by /userinfo even under a stricter profile that would scope-gate them out.
expires_in_minutesNoToken expiration in minutes (optional, default: 60)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are present, so the description carries the full burden, but it only states that a token is generated. It does not disclose side effects, such as refresh-token persistence, auditability, or authorization requirements for this sensitive operation.

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, front-loaded sentence with no filler or repetition. It states the core action efficiently, even though additional context would be welcome elsewhere.

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

Completeness2/5

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

This is a credential-issuing operation among admin/audit tools, with no output schema and no annotations, yet the description provides no context about expected output, permissions, or when to choose it. The schema is rich, but the description leaves important operational context missing.

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 every parameter already has a detailed explanation, including scope persistence and OIDC claims behavior. The description adds no parameter-level meaning, so the baseline of 3 applies.

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 uses a specific verb (Generate), a clear resource (OAuth2 access token), and a beneficiary (for a user). This clearly differentiates it from siblings like decode_token and verify_token, which inspect rather than create tokens.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as verify_token or decode_token. Prerequisites, like admin permissions or conditions for generating a token, are also left entirely to inference.

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