"NestJS" matching MCP tools:

• scaffold_flags_integrationA

  The BridgeA

  Scaffold a flags-only Bridge integration into an existing project — the MCP equivalent of `bridge flag init`. Returns everything that command produces, for YOU to write to disk: the contents of bridge-flags.config.json (app id, app name, base URL, suggested provider config, read live from this Bridge app), the install command, and the framework-specific setup guide fetched from the plugin repo that owns it. Writes nothing — neither to disk nor to the Bridge app. Call this when adding feature flags to a project for the first time; for auth or billing use get_integration_guide with topic=master or topic=billing-master instead. framework is REQUIRED: this server cannot see the caller's disk, so detect it yourself from package.json (next → nextjs, @sveltejs/kit or svelte → svelte, @nestjs/core → nestjs, @angular/core → angular, react → react, express → express; check in that order) and pass it. The returned guide is the same document get_integration_guide returns for topic=feature-flags, so there is no need to call both. Do not invent import specifiers — they differ per plugin and only the guide has the current ones.

  ConnectorOAuth

• get_integration_guideA

  The BridgeA

  Read the Bridge integration guide for a topic — the supported, opinionated way to consume Bridge from application code. Call this BEFORE writing or changing app code that reads a feature flag, renders billing or team UI, or wires authentication, and before hand-rolling anything against the SDK: the SDKs ship declarative surfaces for these cases (components, route guards, decorators) and reimplementing them against SDK internals is the most common integration mistake. Per-framework topics (framework REQUIRED): integration (first-time setup) | auth | feature-flags | billing | team | branding. Framework-agnostic MASTER topics (framework is IGNORED — omit it): master, the end-to-end auth integration prompt served by `bridge guide`, which orchestrates project discovery and then routes to the per-framework guides; flags-master and billing-master, the same orchestration for a flags-only or billing-only integration; mechanisms, how limits, upgrades and customization work; orientation, what Bridge does (the same map get_started returns); fit-together, how roles, plans, limits and flags fit together; integration-success, the message to show the developer when an integration is done. Before setting up flags, roles, plans or limits, read topic=fit-together. Start at topic=master when integrating Bridge into a project for the first time. framework: svelte | react | angular | nextjs | nestjs | express — pass the one the target app actually uses; this server cannot detect it. Returns the guide as markdown plus its source URL. Guidance is a default, not a mandate — follow the user's stated preference when it differs.

  ConnectorOAuth

• create_feature_flagA

  The BridgeA

  Create a new feature flag. Before writing app code that consumes this, call get_integration_guide with topic=feature-flags and the framework the app uses. The result carries `warnings` when the flag cannot mean what it looks like — switched on while its onValue is false, or a rule on a plan or role the app does not have. A warning never blocks the write; read it and fix the flag. Every gate in app code is a flag: flags are the standard way to control a route, an API endpoint, a feature or a piece of code. A feature a plan sells is also listed on the plan, and the flag's rule points at bridge:billing.entitlement.<feature>. Access by who someone is is a rule on a privilege (preferred) or a role; app code never reads a role, privileges, the plan or a plan feature itself. Numbers are plan quotas, not flags; permission on one specific record stays in app code. Full rule: get_integration_guide topic=fit-together. Arguments: key (required — the identifier code reads, e.g. "beta-ui"), description, state (off | on | on-with-rule; defaults to off), valueType (boolean | string | number | json; defaults to boolean), onValue / offValue (the typed values returned in the on / off states — real JSON values, e.g. true, "variant-b", 42, or an object), and rule for state=on-with-rule. A rule is ordered branches of AND-ed conditions, first match wins, else otherwiseValue; the rule argument has the full shape and examples. A feature a plan sells is listed on the plan (add_plan_feature) and the rule points at that list, never at plan names. For who someone is, prefer a privilege rule over a role rule on the role KEY; read the app's real roles with list_roles first. The same rule gives the same answer in the browser and on the NestJS backend. Use update_feature_flag to change an existing flag, and toggle_feature_flag for a quick on/off switch by key.

  ConnectorOAuth

• update_feature_flagA

  The BridgeA

  Update an existing feature flag by its id (get the id from list_feature_flags). Only the fields you pass are changed. Before writing app code that consumes this, call get_integration_guide with topic=feature-flags and the framework the app uses. The result carries `warnings` when the flag cannot mean what it looks like — switched on while its onValue is false, or a rule on a plan or role the app does not have. A warning never blocks the write; read it and fix the flag. Every gate in app code is a flag: flags are the standard way to control a route, an API endpoint, a feature or a piece of code. A feature a plan sells is also listed on the plan, and the flag's rule points at bridge:billing.entitlement.<feature>. Access by who someone is is a rule on a privilege (preferred) or a role; app code never reads a role, privileges, the plan or a plan feature itself. Numbers are plan quotas, not flags; permission on one specific record stays in app code. Full rule: get_integration_guide topic=fit-together. Fields: key, description, state (off | on | on-with-rule), valueType (boolean | string | number | json), onValue / offValue (typed JSON values), rule (replaces the whole rule), clearRule: true to remove the rule entirely. A rule is ordered branches of AND-ed conditions, first match wins, else otherwiseValue; the rule argument has the full shape and examples. A feature a plan sells is listed on the plan (add_plan_feature) and the rule points at that list, never at plan names. For who someone is, prefer a privilege rule over a role rule on the role KEY; read the app's real roles with list_roles first. The same rule gives the same answer in the browser and on the NestJS backend. For a plain on/off switch prefer toggle_feature_flag, which works by key.

  ConnectorOAuth