Skip to main content
Glama

Preview dynamic endpoint

preview_dynamic_endpoint

Render what a dynamic endpoint serves WITHOUT publishing — runs the endpoint's workflow through the full serve path (input + bound datafile + content-type) and returns the response, so you can preview a DRAFT before publishing (or verify any version). Omit version to preview the latest draft; pass a version to preview that one. For a :param endpoint (e.g. 'post/:slug'), pass sample params (e.g. {"slug":"hello"}) — they run through the definition's input_transform, so you can preview a specific URL and confirm a good value renders and a bad one fails input validation. This executes the workflow (may have side effects). Returns content_type, output (decoded as a string), the run status (status=failed with a message when the render did not succeed), the run_id (drill into the full run/traces with get_workflow_run_traces), and resolved_input (the $input the transform produced, for debugging the mapping).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugNothe endpoint slug (provide this or endpoint_id)
paramsNosample path parameters for a :param endpoint (e.g. {"slug":"hello"} for a 'post/:slug' endpoint); fed to the definition's input_transform to build $input, so you can preview a specific URL and confirm it passes the workflow's input_schema
versionNospecific version to preview; omit (0) for the latest version (the draft)
endpoint_idNothe endpoint id (provide this or slug)
viewer_emailNosimulated viewer's email, bound as auth.email. Only takes effect when the endpoint has a role allowlist (auth.allow.tenant_roles) — that is the only case where a real address reaches a workflow, so a preview without one ignores this, exactly as serving would
viewer_rolesNosimulated viewer's roles in this workspace, bound as auth.roles (e.g. ["ROLE_ADMIN"]) so you can preview role-gated rendering. Like viewer_email, only takes effect on an endpoint with a role allowlist
viewer_user_idNosimulate a signed-in viewer for previewing a gated endpoint that exposes identity: the derived auth.viewer_id is computed from this, so the preview shows the real identifier. Omit it and a visible placeholder stands in. Ignored unless the endpoint gates and exposes identity

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
outputYes
run_idNo
statusYes
messageNo
content_typeYes
resolved_inputNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The description openly states that the tool executes the endpoint's workflow and may have side effects, which is consistent with the readOnlyHint=false annotation. It also discloses the full serve path behavior and what is returned, so the agent understands the operational impact beyond the annotation metadata.

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

Conciseness4/5

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

The description is thorough and well-structured but slightly repetitive, particularly around the idea of previewing a specific URL and confirming good/bad values, which appears in both the main description and the params field description. Overall it remains focused and informative, with only minor redundancy.

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 description covers the tool's purpose, side effects, parameter behavior, and return fields (content_type, output, status, run_id, resolved_input). It also explains edge cases like draft vs. version selection, :param endpoints, and role-gated viewers, making it complete for an agent to invoke correctly.

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

Parameters5/5

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

Every parameter is explained with meaningful context beyond the schema: slug/endpoint_id are alternatives, params feed input_transform, version semantics are clarified, and viewer_email/viewer_roles/viewer_user_id are tied to auth binding and role allowlists. The schema coverage is 100% and the description adds substantial value to each field.

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's purpose with a specific verb ('Render what a dynamic endpoint serves WITHOUT publishing') and distinguishes it from publishing or running endpoints by emphasizing draft preview and version verification. It is immediately obvious what the tool does and how it differs from siblings like publish_dynamic_endpoint or run_workflow.

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?

The description explicitly says when to use the tool ('preview a DRAFT before publishing or verify any version'), how to handle :param endpoints with sample params, and how version omission selects the latest draft. It also clarifies viewer-related parameter behavior, giving clear guidance on when those parameters take effect.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources