Skip to main content
Glama

Lint Assembly Instructions

transloadit_lint_assembly_instructions

Validate Transloadit assembly instructions to identify errors before execution, returning structured issue reports for correction.

Instructions

Lint Assembly Instructions without creating an Assembly. Returns structured issues.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
instructionsYes
strictNo
return_fixedNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusYes
linting_issuesYes
normalized_instructionsNo

Implementation Reference

  • The tool handler for 'transloadit_lint_assembly_instructions' which uses createLintClient and processes the result.
    async ({ instructions, strict, return_fixed }) => {
      const client = createLintClient(options)
      const assemblyInstructions =
        instructions as LintAssemblyInstructionsInput['assemblyInstructions']
      const result = await client.lintAssemblyInstructions({
        assemblyInstructions,
        fix: return_fixed ?? false,
        fatal: strict ? 'warning' : 'error',
      })
    
      const payload: Record<string, unknown> = {
        status: result.success ? 'ok' : 'error',
        linting_issues: toLintIssues(result.issues),
      }
    
      if (return_fixed && result.fixedInstructions) {
        payload.normalized_instructions = safeJsonParse(result.fixedInstructions)
      }
    
      return buildToolResponse(payload)
  • The registration of 'transloadit_lint_assembly_instructions' in the McpServer instance.
    server.registerTool(
      'transloadit_lint_assembly_instructions',
      {
        title: 'Lint Assembly Instructions',
        description:
          'Lint Assembly Instructions without creating an Assembly. Returns structured issues.',
        inputSchema: lintAssemblyInputSchema,
        outputSchema: lintAssemblyOutputSchema,
      },
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool 'Returns structured issues,' which gives some insight into output behavior. However, it lacks details on permissions needed, rate limits, error handling, or what 'structured issues' entail (e.g., format, severity levels). For a tool with no annotations, this is a significant gap in transparency.

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?

The description is extremely concise and front-loaded: a single sentence that directly states the tool's action and key constraint. Every word earns its place, with no redundant information or fluff.

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?

Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is minimally adequate. The output schema likely covers return values, reducing the need for description details there. However, the lack of parameter semantics and behavioral context leaves gaps. It meets a baseline but could be more informative.

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

Parameters2/5

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

Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about the parameters (instructions, strict, return_fixed), their meanings, or expected formats. It doesn't compensate for the lack of schema documentation, leaving parameters largely unexplained beyond their names.

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 tool's purpose: 'Lint Assembly Instructions without creating an Assembly. Returns structured issues.' It specifies the verb (lint), resource (Assembly Instructions), and key constraint (without creating an Assembly). However, it doesn't explicitly differentiate from sibling tools like transloadit_create_assembly or transloadit_wait_for_assembly, which are related to actual assembly operations.

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 implies usage context by stating 'without creating an Assembly,' suggesting this tool is for validation before actual assembly creation. However, it doesn't provide explicit guidance on when to use this versus alternatives like transloadit_create_assembly for production or transloadit_list_templates for reference. No exclusions or prerequisites are mentioned.

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/transloadit/node-sdk'

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