Skip to main content
Glama
webflow

Webflow

Official
by webflow

List Applied Scripts

site_applied_scripts_list

Retrieve all custom scripts applied to a Webflow site to manage and audit site functionality and integrations.

Instructions

Get all scripts applied to a site by the App. To apply a script to a site or page, first register it via the Register Script endpoints, then apply it using the relevant Site or Page endpoints.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
site_idYesUnique identifier for the site.

Implementation Reference

  • The handler function that executes the 'site_applied_scripts_list' tool. It fetches the list of applied scripts (custom code) for a given site ID using the Webflow API client and formats the response.
    async ({ site_id }) => {
      try {
        const response = await getClient().sites.scripts.getCustomCode(
          site_id,
          requestOptions
        );
        return formatResponse(response);
      } catch (error) {
        return formatErrorResponse(error);
      }
  • The input schema for the tool, defining the required 'site_id' parameter.
    inputSchema: z.object({
      site_id: z.string().describe("Unique identifier for the site."),
    }),
  • The registration of the 'site_applied_scripts_list' tool using McpServer.registerTool, including title, description, input schema, and handler.
      "site_applied_scripts_list",
      {
        title: "List Applied Scripts",
        description:
          "Get all scripts applied to a site by the App. To apply a script to a site or page, first register it via the Register Script endpoints, then apply it using the relevant Site or Page endpoints.",
        inputSchema: z.object({
          site_id: z.string().describe("Unique identifier for the site."),
        }),
      },
      async ({ site_id }) => {
        try {
          const response = await getClient().sites.scripts.getCustomCode(
            site_id,
            requestOptions
          );
          return formatResponse(response);
        } catch (error) {
          return formatErrorResponse(error);
        }
      }
    );
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions 'Get all scripts' which implies a read operation, but doesn't disclose behavioral traits like whether it returns paginated results, error conditions, authentication requirements, or rate limits. The second sentence about applying scripts adds some context but doesn't fully compensate for the lack of behavioral details.

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 appropriately sized with two sentences. The first sentence directly states the tool's purpose, and the second provides relevant context about script application workflow. There's minimal waste, though the second sentence could be considered slightly tangential to the core listing function.

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

Completeness3/5

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

For a simple single-parameter read tool with no output schema, the description provides adequate basic information about what it does. However, without annotations and with no output schema, it lacks details about return format, error handling, or performance characteristics that would be helpful for an agent. The description is minimally complete but has clear gaps.

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 description coverage is 100% with the single parameter 'site_id' well-documented in the schema. The description doesn't add any additional meaning about the parameter beyond what's already in the schema (e.g., format examples, validation rules). Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb 'Get' and resource 'all scripts applied to a site by the App', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'site_registered_scripts_list' or 'delete_all_site_scripts', which would require mentioning it's a read-only listing operation versus other script management functions.

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

Usage Guidelines3/5

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

The description provides implied usage context by mentioning that to apply scripts, one must first register them via other endpoints, suggesting this tool is for viewing rather than modifying. However, it doesn't explicitly state when to use this tool versus alternatives like 'site_registered_scripts_list' or provide clear exclusions, leaving some ambiguity.

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/webflow/mcp-server'

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