Skip to main content
Glama

list_guardrails

Read-onlyIdempotent

List guardrails in your organization with filters by workspace or organization. Use to retrieve IDs and slugs for managing guardrails.

Instructions

List guardrails in the org with id, slug, status, ownership, and optional workspace/org filters. Use this to find IDs and slugs before get_guardrail, update_guardrail, or delete_guardrail.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workspace_idNoFilter guardrails by workspace ID
organisation_idNoFilter guardrails by organization ID
page_sizeNoNumber of items per page (1-1000, default: 100)
current_pageNoPage number for pagination

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesWhether the tool call succeeded and returned structured data
dataNoStructured success payload when ok is true
errorNoStructured error payload when ok is false

Implementation Reference

  • The handler tool registration for 'list_guardrails'. Calls service.guardrails.listGuardrails(params) and maps the response to include id, name, slug, status, workspace_id, organisation_id, created_at, last_updated_at, owner_id, updated_by.
    export function registerGuardrailsTools(
    	server: McpServer,
    	service: PortkeyService,
    ): void {
    	// List guardrails tool
    	server.tool(
    		"list_guardrails",
    		"List guardrails in the org with id, slug, status, ownership, and optional workspace/org filters. Use this to find IDs and slugs before get_guardrail, update_guardrail, or delete_guardrail.",
    		GUARDRAILS_TOOL_SCHEMAS.listGuardrails,
    		async (params) => {
    			const result = await service.guardrails.listGuardrails(params);
    			return {
    				content: [
    					{
    						type: "text",
    						text: JSON.stringify(
    							{
    								total: result.total,
    								guardrails: result.data.map((guardrail) => ({
    									id: guardrail.id,
    									name: guardrail.name,
    									slug: guardrail.slug,
    									status: guardrail.status,
    									workspace_id: guardrail.workspace_id,
    									organisation_id: guardrail.organisation_id,
    									created_at: guardrail.created_at,
    									last_updated_at: guardrail.last_updated_at,
    									owner_id: guardrail.owner_id,
    									updated_by: guardrail.updated_by,
    								})),
    							},
    							null,
    							2,
    						),
    					},
    				],
    			};
    		},
    	);
  • Input schema for the listGuardrails tool: optional workspace_id, organisation_id, page_size (1-1000), and current_page.
    const GUARDRAILS_TOOL_SCHEMAS = {
    	listGuardrails: {
    		workspace_id: z
    			.string()
    			.optional()
    			.describe("Filter guardrails by workspace ID"),
    		organisation_id: z
    			.string()
    			.optional()
    			.describe("Filter guardrails by organization ID"),
    		page_size: z.coerce
    			.number()
    			.min(1)
    			.max(1000)
    			.optional()
    			.describe("Number of items per page (1-1000, default: 100)"),
    		current_page: z.coerce
    			.number()
    			.positive()
    			.optional()
    			.describe("Page number for pagination"),
    	},
    	getGuardrail: {
    		guardrail_id: z
    			.string()
    			.describe("The guardrail UUID or slug (with guard_ prefix) to retrieve"),
    	},
    	createGuardrail: {
    		name: z.string().describe("Name of the guardrail"),
    		checks: z
    			.array(guardrailCheckSchema)
    			.min(1)
    			.describe("Array of checks to apply (at least one required)"),
    		actions: guardrailActionSchema.describe(
    			"Actions to take when guardrail checks pass or fail",
    		),
    		workspace_id: z
    			.string()
    			.optional()
    			.describe("Workspace ID to create the guardrail in"),
    		organisation_id: z
    			.string()
    			.optional()
    			.describe("Organisation ID (required if workspace_id not provided)"),
    	},
    	updateGuardrail: {
    		guardrail_id: z.string().describe("The guardrail UUID or slug to update"),
    		name: z.string().optional().describe("New name for the guardrail"),
    		checks: z
    			.array(guardrailCheckSchema)
    			.min(1)
    			.optional()
    			.describe("Updated array of checks to apply"),
    		actions: guardrailActionSchema
    			.optional()
    			.describe("Updated actions configuration"),
    	},
    	deleteGuardrail: {
    		guardrail_id: z.string().describe("The guardrail UUID or slug to delete"),
    	},
    } as const;
  • TypeScript interfaces ListGuardrailsParams and ListGuardrailsResponse for the service layer.
    /** Parameters for listing guardrails */
    export interface ListGuardrailsParams {
    	workspace_id?: string;
    	organisation_id?: string;
    	page_size?: number;
    	current_page?: number;
    }
    
    /** Response from listing guardrails */
    export interface ListGuardrailsResponse {
    	data: Guardrail[];
    	total: number;
    }
  • Service implementation of listGuardrails — makes a GET request to /guardrails with query parameters for filtering and pagination.
    export class GuardrailsService extends BaseService {
    	/**
    	 * List all guardrails with optional filtering
    	 */
    	async listGuardrails(
    		params?: ListGuardrailsParams,
    	): Promise<ListGuardrailsResponse> {
    		return this.get<ListGuardrailsResponse>("/guardrails", {
    			workspace_id: params?.workspace_id,
    			organisation_id: params?.organisation_id,
    			page_size: params?.page_size,
    			current_page: params?.current_page,
    		});
    	}
  • The registerGuardrailsTools function is wired into the tool domain registrars array under 'guardrails', and is called by registerAllTools.
    type ToolRegistrar = (server: McpServer, service: PortkeyService) => void;
    
    const TOOL_DOMAIN_REGISTRARS = [
    	["users", registerUsersTools],
    	["workspaces", registerWorkspacesTools],
    	["configs", registerConfigsTools],
    	["keys", registerKeysTools],
    	["collections", registerCollectionsTools],
    	["prompts", registerPromptsTools],
    	["analytics", registerAnalyticsTools],
    	["guardrails", registerGuardrailsTools],
    	["limits", registerLimitsTools],
    	["audit", registerAuditTools],
    	["labels", registerLabelsTools],
    	["partials", registerPartialsTools],
    	["tracing", registerTracingTools],
    	["logging", registerLoggingTools],
    	["providers", registerProvidersTools],
    	["integrations", registerIntegrationsTools],
    	["mcp-integrations", registerMcpIntegrationsTools],
    	["mcp-servers", registerMcpServersTools],
    ] as const satisfies readonly (readonly [string, ToolRegistrar])[];
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds minimal extra behavioral context beyond noting optional filters. Annotations carry the safety burden, so description is adequate.

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, no waste. First sentence states purpose and fields, second sentence gives usage guidance. Front-loaded and efficient.

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?

The tool is a simple list operation with filters. Rich annotations and output schema (present) reduce the need for description. The description covers purpose, usage, and filters completely.

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% with descriptions for all 4 parameters. The description only mentions 'optional workspace/org filters,' which aligns with the schema but does not add new meaning. Baseline 3 is appropriate.

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?

The description clearly states the tool lists guardrails with specific fields (id, slug, status, ownership) and optional filters. It distinguishes from siblings like get_guardrail, update_guardrail, delete_guardrail by explaining its role as a discovery tool.

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?

Explicitly states when to use: 'Use this to find IDs and slugs before get_guardrail, update_guardrail, or delete_guardrail.' This provides clear context and alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/s-b-e-n-s-o-n/portkey-admin-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server