list_blueprints
List blueprints in your organization.
**Without identifiers:** Returns summary list (identifier, title, description, property/relation names).
**With identifiers:** Returns full blueprint details including property definitions, schemas, relations, and enum values.
Use full details when you need:
- Property types for constructing filters
- Enum values for properties
- Relation target blueprints
list_entities
Query entities from a blueprint. All parameters are composable.
**FILTERING:**
- identifiers: Pre-select specific entities by ID
- query: Apply filter rules (can combine with identifiers)
**OUTPUT OPTIONS (composable):**
- groupBy: Get value distribution grouped by property/relation
- countOnly: Include total count in response
- Can request multiple: e.g., groupBy + countOnly returns both groups and total count
**RESPONSE includes:**
- entities + hasMoreEntities: when listing (no groupBy)
- groups + hasMoreGroups: when groupBy is set
- count: when countOnly is true
⚠️ CALL list_blueprints FIRST if filtering by blueprint-specific properties/relations to understand:
1. PROPERTY TYPES: string, number, date, boolean, array - determines valid operators
2. ENUM VALUES: Check schema.properties.{field}.enum for exact values
3. RELATION TARGETS: Check relations.{name}.target for valid entity identifiers
❌ COMMON FAILURES:
- Wrong enum value casing (e.g., "open" instead of "Open")
- Wrong relation target (using service ID for a _user relation)
- Wrong operator for type (e.g., "contains" on non-array)
INCLUDE PARAMETER:
- Use specific identifiers: "status", "assignee", "security-maturity"
- NOT categories: "properties", "relations", "scorecards"
SEARCHING BY NAME:
- Use "contains" on BOTH $identifier AND $title with "or" combinator
- Use single words (e.g., "payment" not "payment gateway")
DATE FILTERING:
- Range: { "property": "created_at", "operator": "between", "value": { "from": "ISO_DATE", "to": "ISO_DATE" } }
- Comparison: { "property": "created_at", "operator": ">=", "value": "ISO_DATE" }
USER IDENTIFIERS:
- _user blueprint uses EMAIL as identifier
- Filter by user: { "relation": "creator", "operator": "=", "value": "
[email protected]" }
FILTERING BY RELATIONS:
- Use "relation" key, NOT "property": { "relation": "assignee", "operator": "=", "value": "..." }
- Single relations: use "="
- Array relations: use "contains" or "containsAny"
SORTING:
- Use "order": "asc" or "desc" (NOT "direction")
list_scorecards
List scorecards in your organization.
**Without identifiers:** Returns summary list (identifier, title, blueprint, levels, compacted rules).
**With identifiers:** Returns full scorecard details including complete rule configurations.
list_actions
List actions in your organization.
**Without identifiers:** Returns summary list (identifier, title, description, trigger type).
**With identifiers:** Returns full action details including complete input schemas.
Use full details when you need the input schema before running an action.
track_action_run
Track action execution status
describe_user_details
Describe the user, which organization he is connected to and what teams he is a member of and more information regarding the user. Can be useful for questions that relate to the user or when looking up for related entities to the user
run_action
Run an action by its identifier.
DISCOVERY WORKFLOW:
1. Use list_actions tool to discover all available actions and their identifiers
2. Use list_actions tool with the specific action identifier to get:
- The exact action definition
- Required input properties and their schemas
- Whether entityIdentifier is needed (check if trigger.blueprintIdentifier exists AND trigger.operation is "DAY-2" or "DELETE")
- Property types, formats, constraints, and required fields
3. Format the properties object according to the action's trigger.userInputs.properties schema
4. Call run_action with the actionIdentifier, properties, and optionally entityIdentifier
ENTITY IDENTIFIER REQUIREMENTS:
- entityIdentifier is ONLY required when trigger.blueprintIdentifier exists AND trigger.operation is "DAY-2" or "DELETE"
- If trigger.blueprintIdentifier is undefined/missing, do NOT provide entityIdentifier regardless of the operation type (including DAY-2 and DELETE)
- Many DAY-2 and DELETE actions do NOT have a blueprintIdentifier and do NOT need an entityIdentifier
- When entityIdentifier IS required, use list_entities tool with the blueprint identifier from trigger.blueprintIdentifier to find valid values
- Do NOT refuse to run an action just because it is DAY-2 or DELETE - check trigger.blueprintIdentifier first
PROPERTY FORMATTING:
- Always check list_actions (with identifiers) response for the exact property schema
- Match property types, formats, and constraints exactly as defined
- Include all required properties as specified in trigger.userInputs.required
load_skill
Load specialized guidance for a domain-specific task.
Skills provide step-by-step instructions for common workflows. Load a skill BEFORE starting a specialized task to ensure consistent, thorough handling.
**Available Skills:**
- action-permissions-helper: Help users configure permissions for self-service actions, with focus on dynamic permission policies. Use when users need help with execute/approve permissions, JQ conditions, or catalog queries for access control.
- mapping-assistant: Help users create, modify, or troubleshoot integration mapping configurations. Use when users ask about mapping, JQ expressions, or data transformation for integrations.
- skill-creator: Create and register custom AI skills in Port. Use when users ask to create a skill, build a skill, write a skill, or ask "Can you create it as a skill?" This skill guides through writing effective skill content and registering it as a Port entity.
- troubleshoot-integration: Diagnose and resolve integration sync issues, mapping errors, and data problems. Use when users report missing data, sync failures, or integration errors.
- troubleshoot-scim: Diagnose and resolve SCIM provisioning issues, including group provisioning errors, missing users, compatibility issues, and login problems. Use when customers report SCIM-related issues with Azure EntraID, Okta, JumpCloud, Google Workspace, or any SCIM 2.0 compatible IdP.
- workflows: Create or update Port workflows with triggers, action nodes, conditions, and data flow. Use when users ask to create, update, or modify a workflow—including adding, updating, or removing individual nodes, connections, or user inputs.
**Usage:**
- load_skill({ name: "skill-name" }) → Returns main instructions + list of available resources
- load_skill({ name: "skill-name", resource: "references/REFERENCE.md" }) → Returns specific resource content
search_port_knowledge_sources
Perform semantic retrieval over the documentation and other knowledge sources of Port and return the most relevant chunks for a given query. A "chunk" is a short, self-contained snippet of text taken from a single page or item within these sources (for example, part of a documentation page) and includes its source URL and markdown content. Chunks are returned in descending order of relevance to the query, and the tool always returns a fixed number of chunks (top-k). If the knowledge sources do not contain information relevant to the query, the returned chunks may be only weakly related or entirely unrelated. Use this tool anytime you need information about Port.