portkey-admin-mcp

list_scim_workspace_mappings

Read-onlyIdempotent

List identity-provider SCIM group mappings that grant Portkey workspace roles. Filter by workspace, group, or role to audit provisioned access or retrieve a mapping ID before deletion.

Instructions

List identity-provider SCIM group mappings that automatically grant Portkey workspace roles. Use it to audit provisioned access or obtain mapping_id before delete_scim_workspace_mapping; filter by workspace, group, or role and page through large directories. This reads mappings only and does not query individual workspace members. Enterprise-gated. Returns 403 on non-Enterprise Portkey plans.

Input Schema

Name	Required	Description
`page`	No	Zero-based results page to retrieve; the first page is 0. These SCIM tools name the parameter page, not the current_page used by other list tools.
`role`	No	Return only mappings that grant this workspace role
`page_size`	No	Mappings per page, from 1 through 100
`workspace_id`	No	Return only mappings for this Portkey workspace UUID (the id from list_workspaces, not its slug)
`scim_group_id`	No	Return only mappings for this identity-provider SCIM group ID

Output Schema

Name	Required	Description
`ok`	Yes	Whether the tool call succeeded and returned structured data
`data`	No	Structured success payload when ok is true
`error`	No	Structured error payload when ok is false

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.0.9Oct 26, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed1 schema field changedv1.0.8Oct 16, 2026

changedInput schema / properties / workspace_id / description

Previous value: -"Return only mappings for this Portkey workspace ID"New value: +"Return only mappings for this Portkey workspace UUID (the id from list_workspaces, not its slug)"

Changed1 schema field changedv0.11.5Sep 8, 2026

changedInput schema / properties / page / description

Previous value: -"Zero-based results page to retrieve; the first page is 0. Unlike current_page used by other list tools in this API (which is 1-based), do not pass 1 for the first page here."New value: +"Zero-based results page to retrieve; the first page is 0. These SCIM tools name the parameter page, not the current_page used by other list tools."

Changed1 schema field changedv1.0.5Aug 10, 2026

changedInput schema / properties / page / description

Previous value: -"Zero-based results page to retrieve; the first page is 0"New value: +"Zero-based results page to retrieve; the first page is 0. Unlike current_page used by other list tools in this API (which is 1-based), do not pass 1 for the first page here."

AddedAug 9, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral facts: Enterprise gating and an explicit 403 on non-Enterprise plans, plus the filtering/paging behavior and its scope limit. None of that is derivable from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with what it does, then use cases, then the sibling hand-off, then the access caveat. No filler; every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation. The description covers the remaining agent-critical gaps: enterprise gating with a specific failure status, use-case routing, and scope limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each parameter's meaning is already documented — including the page vs current_page nuance and the workspace UUID-vs-slug distinction. The description only restates which dimensions can be filtered (workspace, group, role) without adding syntax or format detail, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb (List) and precise resource (identity-provider SCIM group mappings that auto-grant workspace roles), which cleanly separates it from create_scim_workspace_mapping, update_, and delete_scim_workspace_mapping siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names two concrete use cases (audit provisioned access, obtain mapping_id before delete_scim_workspace_mapping) and pairs them with a named sibling. It also states a boundary condition: it reads mappings only and does not query individual workspace members.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server