The PropelAuth Integration MCP Server helps you and your favorite AI agent integrate PropelAuth as quickly and easily as possible into your project. Whether you're integrating PropelAuth into your Next.js project or your FastAPI backend, the Integration MCP Server will ensure your AI agent has the best context possible for a successful integration.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 11 of 11 tools scored.
Each tool targets a distinct scenario (integration vs migration, backend vs frontend vs fullstack, API vs UI vs troubleshooting). Some potential confusion exists between integrate_* and migrate_to_* tools for the same framework, but descriptions clearly distinguish greenfield integration from migration from existing providers.
Two families follow verb-first naming (integrate_*, migrate_to_*), but the other tools use a noun-first pattern (propelauth_backend_api, propelauth_custom_ui, propelauth_troubleshooting). This mix of conventions is readable but not perfectly consistent.
11 tools is well within the appropriate range for an auth integration server. Each tool covers a distinct integration or migration path or a supplemental capability, and none feel redundant or unnecessary.
The tool set provides comprehensive coverage: integration for all major stack types, migration from common providers, user migration, backend API reference, custom UI guidance, and troubleshooting. This covers the full lifecycle of adopting and maintaining PropelAuth with no obvious dead ends.
integrate_propelauth_backendPropelAuth Backend Framework IntegrationAReturns instructions for integrating PropelAuth in a backend framework such as Python, FastAPI, Django, Flask, Rust, Node, Go, Express, and .NET. Guidance includes installation and configuration, protecting API routes, and checking org membership and permissions. It is important to follow the instructions carefully to ensure a successful integration. Do not update the guidance argument unless the user explicitly requests it.
| Name | Required | Description | Default |
|---|---|---|---|
| guidance | No | ||
| backend_framework | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it only returns instructions and includes a specific behavioral rule: 'Do not update the guidance argument unless the user explicitly requests it.' This adds context beyond the annotations and aligns with the readOnlyHint and idempotentHint flags. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main function and is concise overall. The sentence 'It is important to follow the instructions carefully' is generic filler but not distracting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the tool is a read-only instruction provider, the description is sufficiently complete. It covers the main query dimensions (backend framework and guidance topics), though it omits explicit mention of parameter defaults and alternative tool choices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by mapping guidance topics (installation, protecting API routes, org membership) to the guidance enum and listing backend frameworks that align with the backend_framework enum. It adds meaning to both parameters, though it does not explain defaults or null behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Returns instructions for integrating PropelAuth in a backend framework' and lists specific frameworks and guidance topics. This makes the tool's purpose specific and distinguishes it from sibling tools like integrate_propelauth_frontend or fullstack by emphasizing backend scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for backend framework integration, which implies when to use it. However, it does not explicitly mention alternatives or when not to use it, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
integrate_propelauth_frontendPropelAuth Frontend Framework IntegrationAReturns instructions for integrating PropelAuth in a frontend framework such as React, JavaScript, TypeScript, or when using Next.js for just the frontend (e.g. client-side rendered, optionally with API calls; use the integrate_propelauth_fullstack tool for fullstack integration that uses server-side rendering). Guidance includes installation and configuration, creating access tokens, retrieving user or org information, logging users out, redirecting users to login, and more. It is important to follow the instructions carefully to ensure a successful integration. Do not update the guidance argument unless the user explicitly requests it
| Name | Required | Description | Default |
|---|---|---|---|
| guidance | No | ||
| frontend_framework | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds that the tool 'returns instructions' and includes a caution to follow instructions carefully, plus a warning not to update the guidance argument unless explicitly requested. These are useful behavioral constraints beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, all providing substantive information: purpose, examples, differentiation, content scope, and a usage caution. No fluff, though it could be slightly tightened. The last sentence about the guidance argument is an important agent instruction, adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema and readOnlyHint, the description does not need to explain return values. It covers the tool's purpose, alternative tool, content areas, and a usage constraint. The only gap is the parameter value mismatch (TypeScript/Next.js not in schema), which is a minor completeness issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists example guidance topics (installation, access tokens, user info, logout, login) and frontend frameworks (React, JavaScript, TypeScript), but the schema enums only include Javascript and React, creating confusion by mentioning TypeScript and Next.js. It also does not enumerate all guidance values, so it only partially explains the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns instructions for integrating PropelAuth in frontend frameworks, with specific examples (React, JavaScript, TypeScript, Next.js). It also distinguishes itself from the sibling tool integrate_propelauth_fullstack by explicitly naming it, making purpose and differentiation unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs users to use integrate_propelauth_fullstack for fullstack integration with server-side rendering, providing a clear when-not-to-use. It also defines the frontend context (client-side rendered, optionally with API calls). However, it does not contrast with backend or OAuth alternatives, so it is not a full usage guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
integrate_propelauth_fullstackPropelAuth Fullstack Framework IntegrationAReturns instructions for integrating PropelAuth in a fullstack Nextjs App Router or Nextjs Pages Router application. If the user is using Next.js as just a frontend (e.g. client-side rendered with or without server routes), use the integrate_propelauth_frontend tool. Guidance includes installation and configuration, retrieving user or org information, logging users out, redirecting users to login, and more. Do not update the guidance argument unless the user explicitly requests it.
| Name | Required | Description | Default |
|---|---|---|---|
| guidance | No | ||
| fullstack_framework | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds value with the caveat 'Do not update the guidance argument unless the user explicitly requests it,' which clarifies a subtle behavioral constraint beyond standard read-only semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences, each earning its place: purpose, alternative, and parameter caveat. It is front-loaded and free of redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need no explanation. The description covers purpose, scope, alternative, and parameter behavior. It could be slightly more explicit about when to use the backend variant, but for a well-scoped integration-guidance tool it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but both parameters have self-descriptive names and enums in the schema. The description partially compensates by listing example guidance topics ('installation and configuration, retrieving user or org information, logging users out') and by mentioning App Router/Pages Router, which maps to the fullstack_framework enum. However, it adds limited meaning beyond the schema's enums and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope: 'Returns instructions for integrating PropelAuth in a fullstack Nextjs App Router or Nextjs Pages Router application.' It clearly distinguishes from the frontend sibling by naming integrate_propelauth_frontend, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit when-not and alternative: 'If the user is using Next.js as just a frontend ... use the integrate_propelauth_frontend tool.' It also implies the intended context (fullstack Next.js) and lists typical use cases, giving an agent clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
integrate_propelauth_oauthPropelAuth Generic OAuth IntegrationAIMPORTANT: Do NOT fetch all guidances at once. Fetch the 'Backend Installation' guidance first, apply the necessary setup changes, and then fetch subsequent guidances (e.g., 'Redirect users after login', 'Backend Auth Middleware') sequentially as you implement each specific feature. Returns instructions for integrating PropelAuth via OAuth. Only use this tool when specifically instructed to by another tool or the user or if a PropelAuth SDK does not exist for the project's framework. Guidance includes instructions for the backend and frontend, including installation and configuration, creating access tokens, retrieving user or org information, logging users out, redirecting users to login, and more. It is important to follow the instructions carefully to ensure a successful integration.
| Name | Required | Description | Default |
|---|---|---|---|
| guidance | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds a critical behavioral constraint: 'Do NOT fetch all guidances at once. Fetch the 'Backend Installation' guidance first...' This goes beyond the static annotations and provides actionable behavioral guidance. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with an IMPORTANT warning and includes all necessary information, but it is somewhat verbose with multiple clauses and a list of guidance topics. It could be tightened without losing value, but each sentence carries meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description covers purpose, usage conditions, behavioral sequencing, and the scope of returned instructions. It adequately addresses complexity and leaves little ambiguity about when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It references the 'guidance' parameter and gives an example ('Backend Installation') while the schema provides an enum. This adds some meaning about parameter usage but does not enumerate all options or explain each guidance value in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns instructions for integrating PropelAuth via OAuth', using a specific verb and resource. It also distinguishes itself from sibling tools by specifying it is for generic OAuth integration when no SDK exists, which differentiates it from the backend/frontend specific integrations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage conditions: 'Only use this tool when specifically instructed to by another tool or the user or if a PropelAuth SDK does not exist for the project's framework.' It also gives sequential guidance on how to fetch guidances, which is clear contextual instruction. Alternatives are implied by mentioning SDK existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
migrate_to_propelauth_backendMigrate to PropelAuth BackendAReturns instructions for migrating to PropelAuth in a backend framework such as Express, FastAPI, Go, and more; Guidance includes migrating from either Clerk or Auth0. Each guidance will include documentation from the auth provider and PropelAuth. It is important to follow the instructions carefully to ensure a successful integration. It is important to call each guidance individually to ensure a successful integration. IMPORTANT: The backend_framework choice depends on the current auth provider implementation, not just the language. Select 'OAuth' if the backend currently handles the login flow using redirects (e.g., uses express-openid-connect or passport). Select any other option only if the current backend is a pure API that validates JWTs without managing the redirect-based login session. This excludes fullstack Next.js implementations.
| Name | Required | Description | Default |
|---|---|---|---|
| guidance | No | ||
| migrating_from | No | ||
| backend_framework | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior, and the description aligns with this. It adds behavioral context by stating that guidance must be called individually and that each includes documentation from both providers, which enriches the agent's understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, but the description contains redundancy with repeated 'It is important to' phrases and somewhat verbose warnings. The excessive emphasis on carefulness and individual calls could be condensed without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers parameter selection logic, provider sources, and invocation style reasonably well. It explicitly excludes fullstack Next.js implementations, which is useful context. Since an output schema exists, the lack of return format details is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description compensates thoroughly. It explains the critical backend_framework parameter in depth (OAuth vs. pure API), clarifies migrating_from options, and implies the guidance parameter by mentioning 'each guidance' and the need for individual calls. All parameters gain meaningful semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns instructions for migrating to PropelAuth in a backend framework' and specifies the source providers (Clerk or Auth0). It distinguishes itself from sibling integration tools by focusing on migration, and the backend framework scope is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides detailed guidance on when to use the 'OAuth' backend_framework value versus other options, based on the current auth implementation. It also instructs the agent to 'call each guidance individually' for successful integration, though it does not explicitly compare against sibling migrate/integrate tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
migrate_to_propelauth_frontendMigrate to PropelAuth FrontendAReturns instructions for migrating to PropelAuth in a frontend framework such as React, JavaScript, TypeScript, or when using Next.js for just the frontend (e.g. client-side rendered). Guidance includes migrating from several auth providers, such as Clerk or Auth0. Each guidance will include documentation from the auth provider and PropelAuth. It is important to follow the instructions carefully to ensure a successful integration. Make sure to use the 'Installation' guidance first. It is important to call every guidance to ensure a successful integration. Do not update a component/hook/etc from the auth provider until you receive guidance about that component/hook/etc. CRITICAL: If the current implementation uses a traditional OAuth/OIDC flow (e.g., via express-openid-connect, passport-auth0, or similar backend-managed session libraries), you MUST select 'OAuth' as the framework, regardless of the frontend library (React/Vue/etc.). Only select 'React' or 'Javascript' if the current implementation uses a frontend-only SDK (like @auth0/auth0-react) or if using fullstack Next.js.
| Name | Required | Description | Default |
|---|---|---|---|
| guidance | No | ||
| migrating_from | No | ||
| frontend_framework | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds important behavioral context beyond annotations: it returns instructions rather than making changes, requires sequential invocation of guidance, and warns against updating components until receiving relevant guidance. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. It leads with the core purpose, then covers scope, migration sources, critical sequencing rules, and the OAuth exception. Despite its length, it remains focused and structured, with the most critical warning clearly emphasized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the output schema, and the strong annotations, the description provides complete context. It covers the tool's scope, special cases, and procedural requirements, leaving no significant ambiguity about how to use the tool correctly. The return format is adequately handled by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It meaningfully explains the 'frontend_framework' parameter by defining when to use 'OAuth' vs 'React'/'Javascript', and clarifies the 'guidance' parameter by mandating 'Installation' first and calling every guidance. However, the individual enum values for 'guidance' are not fully elaborated beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns instructions for migrating to PropelAuth in a frontend framework' and specifies supported contexts (React, JavaScript, TypeScript, Next.js frontend). It distinguishes from siblings by its focus on frontend migration and explicitly separates the OAuth case from React/Javascript frameworks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: which frontend frameworks are covered, when to choose 'OAuth' vs 'React'/'Javascript', and a critical exclusion for traditional OAuth/OIDC flows. It also gives operational instructions like 'use the Installation guidance first' and 'call every guidance to ensure a successful integration'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
migrate_to_propelauth_fullstackMigrate to PropelAuth FullstackAReturns instructions for migrating from an existing auth provider to PropelAuth in a fullstack Nextjs App Router or Nextjs Pages Router application. If the user is using Next.js as just a frontend (e.g. client-side rendered with or without server routes), use the migrate_to_propelauth_frontend tool. Guidance includes installation and configuration, retrieving user or org information, logging users out, redirecting users to login, and more. Make sure to use the 'Installation' guidance first. It is important to call every guidance to ensure a successful integration. Do not update a component/hook/etc from the auth provider until you receive guidance about that component/hook/etc
| Name | Required | Description | Default |
|---|---|---|---|
| guidance | No | ||
| migrating_from | No | ||
| fullstack_framework | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnlyHint, idempotentHint, and destructiveHint, the description adds valuable behavioral context: it returns instructions (not performing the migration), warns to call every guidance and not to update components/hooks until specific guidance is received, and implies a sequential workflow. This enriches the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the primary purpose, and every sentence adds distinct value: purpose, alternative tool usage, list of guidance topics, and critical warnings about order and updating. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (so return values need not be explained), annotations covering safety, and only three optional parameters with enums, the description is highly complete. It covers when to use, how to use, and important caveats, making it sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description compensates by explaining the 'guidance' parameter's purpose ('Guidance includes installation and configuration, retrieving user or org information, logging users out, redirecting users to login, and more') and the need to call it repeatedly. It also relates 'fullstack_framework' to Next.js App Router/Pages Router. However, 'migrating_from' is only implied via 'existing auth provider', not explicitly tied to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Returns instructions for migrating from an existing auth provider to PropelAuth in a fullstack Nextjs App Router or Nextjs Pages Router application.' It identifies a specific verb, resource, and scope, and distinguishes itself from the sibling tool by explicitly referencing migrate_to_propelauth_frontend for frontend-only use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: says to use migrate_to_propelauth_frontend when Next.js is used as just a frontend, and instructs to use the 'Installation' guidance first and call every guidance for a successful integration. This goes beyond basic context by giving a clear alternative and step-by-step process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
migrate_to_propelauth_usersMigrate users and organizations to PropelAuthAReturns instructions for migrating users and organizations to PropelAuth from other auth providers, such as Clerk. Each guidance will include documentation from the other auth provider and PropelAuth.
| Name | Required | Description | Default |
|---|---|---|---|
| migrating_from | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds beyond this by stating it 'Returns instructions' and that each guidance includes documentation from both the other provider and PropelAuth. This clarifies the read-only, instructional nature and gives insight into the output, aligning with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the purpose and add one relevant detail about the output. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema, existing annotations, and presence of an output schema, the description sufficiently covers the tool's behavior and purpose. It could more explicitly define the `migrating_from` parameter, but overall it is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter `migrating_from` is 0%, so the description must compensate. It indirectly references the parameter via 'such as Clerk,' but does not explicitly explain that `migrating_from` specifies the source provider or what a null value means. The description adds some meaning but not enough to fully cover the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns instructions for migrating users and organizations to PropelAuth from other auth providers, such as Clerk.' It uses a specific verb ('returns instructions') and names the resource (users and organizations) and source (other auth providers), distinguishing it from sibling tools that focus on integration or specific backend/frontend migration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when migrating user and organization data from providers like Clerk. However, it does not explicitly name alternative tools or exclude other scenarios, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
propelauth_backend_apiPropelAuth Backend APIAReturns instructions and provides examples for using PropelAuth's backend APIs. Examples include APIs for users, organizations, Enterprise SSO (SAML/OIDC), API Keys, and Step Up MFA/2FA. Before using this tool, make sure you have installed PropelAuth's backend SDK for your framework (use the 'integrate_propelauth_backend' tool). If an SDK is not available for your framework, you can use the 'Other' option for the framework argument.
| Name | Required | Description | Default |
|---|---|---|---|
| guidance | No | ||
| framework | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds that it 'Returns instructions and provides examples', which is consistent with a non-destructive read-only tool. It does not go deeper into behavior (e.g., output format or pagination), but given annotations and output schema, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose, and every sentence earns its place. It efficiently covers purpose, examples, and prerequisites without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a reference tool with an output schema and enum-driven parameters, the description covers the core purpose and prerequisite. It does not explain the return value format, but the output schema handles that. It could mention that guidance selects a specific example, but the enum values in the schema make this inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the framework argument and the 'Other' option, and lists example categories (users, organizations, SSO, API keys, MFA) that map to the guidance enum. However, it does not explicitly describe the guidance parameter's role or that both parameters are optional, leaving some semantics to be inferred from the schema enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Returns instructions and provides examples for using PropelAuth's backend APIs', specifying the verb and resource. It also distinguishes from sibling tools like integrate_propelauth_backend by clarifying it is a documentation/reference tool rather than an integration tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Before using this tool, make sure you have installed PropelAuth's backend SDK for your framework (use the 'integrate_propelauth_backend' tool).' This names an alternative tool and gives a prerequisite. However, it does not explicitly state when NOT to use this tool (e.g., for frontend tasks), so it lacks full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
propelauth_custom_uiPropelAuth Custom UIAReturns instructions and provides examples for using PropelAuth's frontend APIs to create custom UIs to replace PropelAuth's hosted pages. Examples include login and signup pages, MFA flows, managing organizations, inviting, removing, or updating users in an organization, managing and creating API keys, updating the user's email, verifying MFA, the org member table, api key tables, updating user properties, updating org membership, and more. Before installing any component, make sure to use the 'Installation' guidance first. If instructed to build a login or signup related UI, use the 'LOGIN_AND_SIGNUP_INSTALLATION' guidance first.
| Name | Required | Description | Default |
|---|---|---|---|
| guidance | No | ||
| framework | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds behavioral context by stating it 'returns instructions and provides examples' and emphasizes the need to follow installation guidance first, which helps prevent misuse. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences. The first clearly states the tool's purpose and gives a comprehensive list of examples; the second provides a concise, actionable prerequisite. Every part serves a purpose, and the length is justified for the breadth of the tool's coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex domain (many UI scenarios) and an output schema. The description covers the purpose, the scope of examples, and key usage instructions, which is sufficient for an agent to decide when to invoke it and what to pass. It does not describe the exact return structure, but the presence of an output schema reduces that burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the parameters use descriptive enums (e.g., guidance lists many specific tasks, framework lists JS/React/Next.js variants), which carry much of the meaning. The description adds value by highlighting 'Installation' and 'LOGIN_AND_SIGNUP_INSTALLATION' as key guidance values, but it does not explain the framework parameter or enumerate all guidance options beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'returns instructions and provides examples for using PropelAuth's frontend APIs to create custom UIs to replace PropelAuth's hosted pages.' This uses a specific verb (returns/provides) and resource (custom UI guidance), and is distinct from sibling tools like integrate_propelauth_frontend which handle integration rather than custom UI replacement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit sequencing guidance: 'Before installing any component, make sure to use the 'Installation' guidance first' and 'If instructed to build a login or signup related UI, use the 'LOGIN_AND_SIGNUP_INSTALLATION' guidance first.' This clarifies when to use specific guidance values, though it does not explicitly contrast with alternative tools or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
propelauth_troubleshootingAInspectReturns instructions and guidance on how to resolve common troubleshooting issues. Examples include debugging infinite redirects, third-party cookie issues, access tokens expiring, random logouts, CORS issues, 404 errors when using OAuth, incorrect API key errors, and incorrect verifier key errors.
| Name | Required | Description | Default |
|---|---|---|---|
| guidance | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently states the tool returns instructions and guidance, implying a non-destructive, informational read operation. The examples illustrate the covered topics, though it does not explicitly state the absence of side effects or limitations, which is acceptable for a simple help tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, the second lists examples. It is front-loaded, uses no redundant words, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple informational tool with one optional parameter and an output schema, the description is complete enough. It covers the purpose and examples, though it could explicitly tie the guidance parameter to the listed topics. The existence of an output schema means return value details are unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists example issues that map to the enum values in the schema but never explicitly connects them to the 'guidance' parameter. With 0% schema description coverage, the description should explain how to use the parameter; it only provides examples without stating that passing a topic selects the corresponding instructions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns instructions and guidance for common troubleshooting issues. The verb 'returns' and direct object 'instructions and guidance' precisely define the function, and the examples (infinite redirects, CORS, etc.) clarify scope. It is distinct from the sibling integration/migration tools, which focus on setup rather than troubleshooting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool by listing common scenarios such as infinite redirects and CORS issues. It does not explicitly mention alternatives or exclusions, but the sibling tools are clearly for integration/migration, making the troubleshooting use case well-differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
