Manage IDP
Create service catalog templates, self-service workflows, documentation, ADRs, and developer onboarding flows in Harness Internal Developer Portal.
Instructions
Step 1: Establish Scope
Confirm the user's org and project context.
Call MCP tool: harness_list
Parameters:
resource_type: "project"
org_id: "<organization>"
Step 2: Identify the IDP Task
Determine which IDP workflow the user needs:
- Service Catalog Template -- Standardized microservice template with scaffolding, CI/CD, and observability
- Self-Service Environment Provisioning -- On-demand environment creation with IaC and RBAC controls
- Service Documentation -- Generate catalog-info.yaml, API docs, and architecture overviews
- Architecture Decision Record (ADR) -- Structured decision documentation
- Developer Onboarding -- Automated Day 1 onboarding workflow
Step 3: Create Service Catalog Template
Gather from the user:
- Technology stack (Node.js, Java, Python, Go, etc.)
- Service pattern (REST API, gRPC, event-driven, etc.)
- Container registry for Docker images
- Observability stack (Datadog, Prometheus, etc.)
Template components to generate:
- Application scaffolding with standard dependencies
- CI pipeline: build, test, security scan, Docker build and push
- CD pipeline: deploy to dev, staging, production with approvals
- Observability: health endpoints, metrics, structured logging, dashboards
- catalog-info.yaml with ownership metadata and SLO links
Call MCP tool: harness_create
Parameters:
resource_type: "template"
org_id: "<organization>"
project_id: "<project>"
body:
name: "<stack>-microservice-template"
identifier: "<stack>_microservice_template"
versionLabel: "1.0.0"
type: "Pipeline"
yaml: |
template:
name: <stack>-microservice-template
identifier: <stack>_microservice_template
versionLabel: "1.0.0"
type: Pipeline
spec:
stages:
- stage:
name: Build
type: CI
spec:
# Build, test, scan, push
- stage:
name: Deploy Dev
type: Deployment
spec:
# Deploy to dev environment
Step 4: Create Self-Service Environment Provisioning
Gather from the user:
- Environment type (dev, staging, QA, ephemeral)
- Cloud provider and IaC tool (Terraform, Pulumi, CloudFormation)
- Max concurrent environments per developer
- TTL for ephemeral environments
Design the workflow with:
- Pre-approved infrastructure modules
- Database provisioning with test data seeding
- Secret injection from Harness Secrets or Vault
- RBAC: developer can create/destroy own environments
- Cost controls: TTL-based auto-cleanup, budget caps
Step 5: Generate Service Documentation
When asked to create documentation, gather:
- Service name, team, type (backend, frontend, data pipeline)
- Tech stack, repo URL, environments
- API endpoints and dependencies
Generate:
- catalog-info.yaml -- Backstage-compatible service registration
- API documentation -- Endpoint inventory with request/response schemas
- Architecture overview -- Component diagram, data flow, dependencies
- Operational guide -- Deployment, monitoring, incident response links
Step 6: Create Architecture Decision Record (ADR)
Gather from the user:
- Decision title and context
- Options considered with pros/cons
- Decision made and rationale
- Consequences and follow-up actions
Format as standard ADR:
- Status (Proposed, Accepted, Deprecated, Superseded)
- Context, Decision, Consequences sections
- Link to related ADRs if applicable
Step 7: Design Developer Onboarding Workflow
Gather from the user:
- New engineer's role, team, and tech stack
- Required access (repos, environments, tools)
- Mentorship and buddy program details
Design a self-service onboarding workflow with:
- Access provisioning (GitHub org, Harness project, cloud accounts)
- CDE setup with pre-configured workspace
- First task assignment with guided walkthrough
- Week 1 and Week 2 milestone checklists
Examples
- "Create a microservice template for our Node.js services" -- Generate service catalog template with CI/CD, observability, and catalog-info.yaml
- "Set up self-service environments for developers" -- Create IDP workflow for on-demand environment provisioning
- "Generate documentation for the checkout-service" -- Create catalog-info.yaml, API docs, and architecture overview
- "Write an ADR for our migration from REST to gRPC" -- Create structured ADR with context, decision, and consequences
- "Design an onboarding workflow for new backend engineers" -- Create Day 1 self-service workflow with access, CDE, and milestones
Performance Notes
- Service catalog templates should be tested end-to-end before publishing -- a broken template degrades developer trust.
- Self-service environments need cost guardrails (TTL, budget caps) to prevent cloud spend overruns.
- catalog-info.yaml must conform to Backstage entity schema -- validate before registering.
- ADRs should reference the IDP portal URL so they are discoverable alongside the service catalog.
- Onboarding workflows should be idempotent -- re-running should not create duplicate resources.
Troubleshooting
Template Not Appearing in Catalog
- Verify the template YAML is valid and the identifier matches the directory name
- Check that the template is published (not draft) and the version label is set
- Confirm the user has read access to the org/project where the template lives
Self-Service Workflow Failing
- Check IaC module permissions -- the service account needs create/destroy access in the target cloud
- Verify secret references are resolvable in the target project scope
- Check TTL cleanup jobs are not conflicting with active environments
Documentation Out of Date
- Regenerate catalog-info.yaml when ownership or dependencies change
- Link API docs to the CI pipeline so they auto-update on merge
1---2name: manage-idp3description: Manage Harness Internal Developer Portal (IDP) resources via MCP. Create service catalog templates, configure self-service environment provisioning workflows, generate service documentation, create Architecture Decision Records (ADRs), and design developer onboarding workflows. Use when asked to set up a service catalog, create self-service workflows, generate service docs, write ADRs, or onboard new developers. Do NOT use for service scorecards (use scorecard-review instead). Trigger phrases: service catalog, self-service, developer portal, IDP, onboarding workflow, ADR, architecture decision, service documentation, catalog template, developer experience, backstage.4license: Apache-2.05---67# Manage IDP89Create service catalog templates, self-service workflows, documentation, ADRs, and developer onboarding flows in Harness Internal Developer Portal.1011## Instructions1213### Step 1: Establish Scope1415Confirm the user's org and project context.1617```18Call MCP tool: harness_list19Parameters:20 resource_type: "project"21 org_id: "<organization>"22```2324### Step 2: Identify the IDP Task2526Determine which IDP workflow the user needs:27281. **Service Catalog Template** -- Standardized microservice template with scaffolding, CI/CD, and observability292. **Self-Service Environment Provisioning** -- On-demand environment creation with IaC and RBAC controls303. **Service Documentation** -- Generate catalog-info.yaml, API docs, and architecture overviews314. **Architecture Decision Record (ADR)** -- Structured decision documentation325. **Developer Onboarding** -- Automated Day 1 onboarding workflow3334### Step 3: Create Service Catalog Template3536Gather from the user:37- Technology stack (Node.js, Java, Python, Go, etc.)38- Service pattern (REST API, gRPC, event-driven, etc.)39- Container registry for Docker images40- Observability stack (Datadog, Prometheus, etc.)4142Template components to generate:431. Application scaffolding with standard dependencies442. CI pipeline: build, test, security scan, Docker build and push453. CD pipeline: deploy to dev, staging, production with approvals464. Observability: health endpoints, metrics, structured logging, dashboards475. catalog-info.yaml with ownership metadata and SLO links4849```50Call MCP tool: harness_create51Parameters:52 resource_type: "template"53 org_id: "<organization>"54 project_id: "<project>"55 body:56 name: "<stack>-microservice-template"57 identifier: "<stack>_microservice_template"58 versionLabel: "1.0.0"59 type: "Pipeline"60 yaml: |61 template:62 name: <stack>-microservice-template63 identifier: <stack>_microservice_template64 versionLabel: "1.0.0"65 type: Pipeline66 spec:67 stages:68 - stage:69 name: Build70 type: CI71 spec:72 # Build, test, scan, push73 - stage:74 name: Deploy Dev75 type: Deployment76 spec:77 # Deploy to dev environment78```7980### Step 4: Create Self-Service Environment Provisioning8182Gather from the user:83- Environment type (dev, staging, QA, ephemeral)84- Cloud provider and IaC tool (Terraform, Pulumi, CloudFormation)85- Max concurrent environments per developer86- TTL for ephemeral environments8788Design the workflow with:89- Pre-approved infrastructure modules90- Database provisioning with test data seeding91- Secret injection from Harness Secrets or Vault92- RBAC: developer can create/destroy own environments93- Cost controls: TTL-based auto-cleanup, budget caps9495### Step 5: Generate Service Documentation9697When asked to create documentation, gather:98- Service name, team, type (backend, frontend, data pipeline)99- Tech stack, repo URL, environments100- API endpoints and dependencies101102Generate:1031. **catalog-info.yaml** -- Backstage-compatible service registration1042. **API documentation** -- Endpoint inventory with request/response schemas1053. **Architecture overview** -- Component diagram, data flow, dependencies1064. **Operational guide** -- Deployment, monitoring, incident response links107108### Step 6: Create Architecture Decision Record (ADR)109110Gather from the user:111- Decision title and context112- Options considered with pros/cons113- Decision made and rationale114- Consequences and follow-up actions115116Format as standard ADR:117- Status (Proposed, Accepted, Deprecated, Superseded)118- Context, Decision, Consequences sections119- Link to related ADRs if applicable120121### Step 7: Design Developer Onboarding Workflow122123Gather from the user:124- New engineer's role, team, and tech stack125- Required access (repos, environments, tools)126- Mentorship and buddy program details127128Design a self-service onboarding workflow with:129- Access provisioning (GitHub org, Harness project, cloud accounts)130- CDE setup with pre-configured workspace131- First task assignment with guided walkthrough132- Week 1 and Week 2 milestone checklists133134## Examples135136- "Create a microservice template for our Node.js services" -- Generate service catalog template with CI/CD, observability, and catalog-info.yaml137- "Set up self-service environments for developers" -- Create IDP workflow for on-demand environment provisioning138- "Generate documentation for the checkout-service" -- Create catalog-info.yaml, API docs, and architecture overview139- "Write an ADR for our migration from REST to gRPC" -- Create structured ADR with context, decision, and consequences140- "Design an onboarding workflow for new backend engineers" -- Create Day 1 self-service workflow with access, CDE, and milestones141142## Performance Notes143144- Service catalog templates should be tested end-to-end before publishing -- a broken template degrades developer trust.145- Self-service environments need cost guardrails (TTL, budget caps) to prevent cloud spend overruns.146- catalog-info.yaml must conform to Backstage entity schema -- validate before registering.147- ADRs should reference the IDP portal URL so they are discoverable alongside the service catalog.148- Onboarding workflows should be idempotent -- re-running should not create duplicate resources.149150## Troubleshooting151152### Template Not Appearing in Catalog153- Verify the template YAML is valid and the identifier matches the directory name154- Check that the template is published (not draft) and the version label is set155- Confirm the user has read access to the org/project where the template lives156157### Self-Service Workflow Failing158- Check IaC module permissions -- the service account needs create/destroy access in the target cloud159- Verify secret references are resolvable in the target project scope160- Check TTL cleanup jobs are not conflicting with active environments161162### Documentation Out of Date163- Regenerate catalog-info.yaml when ownership or dependencies change164- Link API docs to the CI pipeline so they auto-update on merge