Feature ideas

Expose an MCP of Port with tools LLMs and AI Agents can use to interact and get information from Port

The ability to add custom headers that will be applied for the entire API spec. So that as a Port member, I will be to step into a service API spec, add a custom header once and it will be applied for all of my API routes in the API spec.

Add support for custom properties https://docs.github.com/en/rest/repos/custom-properties?apiVersion=2022-11-28#get-all-custom-property-values-for-a-repository

Currently, when fetching ECS resources through the AWS integration, it is possible to retrieve details of an ECS Service but not the status of running containers. This limitation arises because the CloudControl API does not provide access to container-level status and other dynamic data. Introducing a dedicated ECS Service resource kind will allow this information to be retrieved through the ECS API, enabling more comprehensive visibility into the state and performance of ECS Services.

Currently the New Relic integration enables 2 API templates to retrieve data. 1. "entitySerach" query - for retrieving New Relic services and APM, SLOs, and cloud resources "aiIssue" query - for retrieving alerts. A major part of the alerts for a specific service/ APM is not connected to the service/ APM but to their container. Therefore, when retrieving alerts' connected services and APMs entityGuids from new relic, we should also retrieve entityGuid of APM/Services if their containers are connected to the alert (as part of the __APPLICATION, and __SERVICE objects)

As a Port Enterprise customer, I'd like to have a my dev and prod environment connected to the same Github application - so that I can dogfood and test features with my real data before releasing it on prod org.

For security use cases, integration with Blackduck for retrieving vulnerabilities, issues, etc

For customers who have a large amount of orgs in their GH environment and want to have one setup for all of them. Today, for it to happen you need to: 1) Register the Port GH app in your self hosted instance 2) Deploy the Port GH self hosted container in your premise 3) The problematic part - Install the app in each org and manage its mapping Ideally we would want to have the ability to manage an Environment wide mapping, for all orgs

The feature request is to limit the deployment-history resource from Argo CD when there is high volume. Do not pull all the history into Port via the integration. The preference is not to use the query parameter filter in the mapping but restricting the data before that. For example, providing an option to add a parameter to the Argo CD ocean client.