Feature ideas

We take your ideas seriously! Read more on our prioritization process in our blog https://productmanagement.port.io/posts/managing-feature-ideas
Support OAuth 2.0 Token Exchange (RFC 8693) with external IdPs on the Port MCP token endpoint
Customers want to build server-side apps that call Port MCP ( https://mcp.port.io/v1 ) on behalf of individual users, with each call running under that user's own Port identity and permissions. Today the only way to do this is the authorization_code flow, which means every user has to link their Port account separately. These customers already sign in to their apps and to Port with an external IdP (e.g. Microsoft Entra ID SSO), so they want a single sign-in to cover both their app and Port. Request: Add the urn:ietf:params:oauth:grant-type:token-exchange grant (RFC 8693) to https://mcp.port.io/v1/token (and the US equivalent, mcp.us.port.io ). The client would send an access token issued by a trusted external IdP (e.g. Entra ID) as the subject_token and get back a Port access token for the matching Port user. Admins would need a way to configure which issuers they trust, the expected audience or scope, and which client registrations are allowed to exchange tokens. Current behavior: The token endpoint metadata (/.well-known/oauth-authorization-server) lists only authorization_code, refresh_token and client_credentials. client_credentials doesn't fit this use case, because it is a machine identity with no per-user permissions. Related: There is an existing roadmap idea for token exchange on the Port API: https://roadmap.getport.io/admin/board/ideas/p/token-exchange-mechanism-for-api-authentication This request is specifically about the MCP server. Customer: Abu Dhabi Investment Authority (ADIA), org_jRQbsFhFMow9ywPM, EU Zendesk: https://getport.zendesk.com/agent/tickets/12235
1
·
AI agents
Hierarchical, LLM-friendly documentation discovery
Port's llms.txt is useful, but it can provide far more context than an agent needs for a specific task, which means unnecessary token usage. I would like Port's documentation to expose a lightweight, hierarchical index that lets LLMs progressively discover the right documentation instead of loading a large representation of the docs upfront. For example, an agent trying to understand GitHub mappings should be able to follow a path like: Docs → Integrations → GitHub → Mapping → Relevant documentation page Each level would only need enough information to help the model decide which branch to follow. For example, a root index could conceptually contain: { "sections": [ { "name": "Software Catalog", "description": "Blueprints, entities, relations and catalog modelling", "index": "..." }, { "name": "Self-service", "description": "Actions, workflows and developer self-service", "index": "..." }, { "name": "Integrations", "description": "GitHub, Jira, Kubernetes, cloud providers and other integrations", "index": "..." } ] } The Integrations index would then expose its children, and so on until the agent reaches the relevant page. This does not have to be JSON. JSON is only one possible implementation. The important part is providing a stable, machine-readable, hierarchical way for agents to understand: What documentation sections exist What each section/page is about What child topics exist underneath it Where to go next for a particular topic Which actual documentation page contains the detailed information Individual pages could also expose short intent hints such as: Use this page for: - Creating GitHub resource mappings - Mapping repositories into Port entities - Configuring JQ mappings This would help an agent distinguish between similarly named sections without reading the full page. The goal is progressive context loading. Instead of: Agent → load llms.txt → receive a large amount of documentation context → search through it the agent could do: Agent → load small docs index → select Integrations → select GitHub → select Mapping → load only the relevant documentation This would reduce token usage, reduce irrelevant context, and make Port's documentation easier for coding agents and long-running AI workflows to navigate. I think this becomes especially useful for tasks like: > "Build this portal using Port." An agent working on that task may need to consult the documentation repeatedly. Giving it a small semantic tree to navigate would be much more efficient than repeatedly loading broad documentation context. llms.txt can still remain as the broad-context option. This would complement it with a more token-efficient discovery mechanism.
0
·
AI agents
Load More
→