Skip to main content
Glama
deenesjakoruzh
VULK-dev

VULK MCP Server

by VULK-dev
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

VULK MCP Server

VULK's MCP connector lets AI assistants generate, edit, inspect, and deploy VULK projects from chat.

Positioning: prompt-to-immersive-site. Agents can ask VULK for 3D/WebGL, cinematic, video-rich, moodboard-driven, full-stack web projects and get back preview/editor/deploy URLs.

This package is the local stdio MCP server. The public remote connector uses the same tool surface at https://mcp.vulk.dev/mcp over HTTPS Streamable HTTP with OAuth 2.0 / PKCE.

What VULK Does

  • Creates production VULK projects from natural-language briefs.

  • Generates immersive web experiences using VULK's internal generation pipeline.

  • Edits existing projects from chat instructions.

  • Lists and inspects projects owned by the authenticated account.

  • Returns file manifests safely by default; content must be explicitly requested.

  • Deploys eligible projects to production.

The connector does not expose provider API keys, internal prompts, customer data outside the authenticated account, or standalone raw media-generation tools.

Related MCP server: @forgespace/ui-mcp

Quick Setup

Remote connector URL for Claude/Codex/agents that support remote MCP:

https://mcp.vulk.dev/mcp

The remote endpoint discovers OAuth through:

  • https://mcp.vulk.dev/.well-known/oauth-protected-resource/mcp

  • https://vulk.dev/.well-known/oauth-authorization-server

Local stdio setup:

Get an API key at https://vulk.dev/settings/api-keys.

{
  "mcpServers": {
    "vulk": {
      "command": "npx",
      "args": ["-y", "vulk-mcp-server"],
      "env": {
        "VULK_API_KEY": "vk_sk_your_key_here"
      }
    }
  }
}

For public/review environments, disable legacy aliases so reviewers see only the clean tool names:

{
  "env": {
    "VULK_API_KEY": "vk_sk_your_key_here",
    "VULK_ENABLE_LEGACY_TOOLS": "false"
  }
}

Primary Tools

  • create_visual_brief - turn a raw idea, visual reference, URL, Figma, screenshot, video reference, or moodboard into a VULK-ready production brief. Read-only.

  • generate_immersive_site - generate a 3D/WebGL, cinematic, video-rich, or moodboard-driven VULK web project. Creates a project and may consume credits.

  • create_project - generate a general VULK project from a prompt.

  • edit_project - apply a natural-language change to an existing VULK project.

  • list_projects - list projects owned by the authenticated account.

  • get_project - get project metadata plus preview/editor URLs.

  • get_project_files - get a project file manifest; content is opt-in, redacted, and size-limited.

  • deploy_project - deploy a project to production.

  • list_models - list available VULK models for the account.

  • get_usage - inspect credits, usage, and rate limits.

  • subscribe - return a VULK pricing URL.

Legacy aliases (generate, edit, list, get, files, deploy, models, usage) remain enabled by default for existing local users. Set VULK_ENABLE_LEGACY_TOOLS=false for the public connector surface.

Security Defaults

  • All tools call VULK first-party APIs only.

  • Authentication uses VULK_API_KEY for this local package. The remote MCP uses OAuth 2.0 with PKCE, dynamic client registration, scoped opaque access tokens, and refresh-token rotation.

  • Tool annotations mark read-only, write, and destructive operations for compatible clients.

  • get_project_files returns only a manifest unless includeContent=true.

  • Sensitive-looking files such as .env, private keys, credentials, service-account files, .npmrc, and certificate/key files are redacted.

  • File content responses are capped to 50 KB by default and 200 KB maximum.

  • Edit context sent back to VULK is capped by VULK_MCP_MAX_EDIT_CONTEXT_BYTES and excludes sensitive-looking paths.

  • The backend validates project ownership before generation or file mutation.

Environment Variables

Variable

Required

Default

Description

VULK_API_KEY

Yes

-

VULK API key starting with vk_sk_.

VULK_API_BASE

No

https://vulk.dev

VULK API base URL.

VULK_ENABLE_LEGACY_TOOLS

No

true

Set to false for the public review surface.

VULK_MCP_MAX_EDIT_CONTEXT_BYTES

No

2000000

Max safe file context sent for edits.

Distribution Targets

  • Local MCP package: npx -y vulk-mcp-server

  • Remote MCP: https://mcp.vulk.dev/mcp

  • Official MCP Registry: server.json

  • Smithery: smithery.yaml

  • Glama: glama.json

  • Gemini CLI: gemini-extension.json

  • Codex plugin bundle: codex-plugin/

  • Claude Connectors Directory: use the remote OAuth MCP build described in docs/CLAUDE_CONNECTOR_SUBMISSION.md

  • Codex extensions/plugins: use the plugin and marketplace plan in docs/UNIVERSAL_AGENT_CONNECTOR.md

Development

npm install
npm run build
VULK_API_KEY=vk_sk_... node dist/index.js

License

MIT

Available Tools

19 tools
create_projectCreate VULK ProjectAInspect

Create a complete VULK project from a prompt and return project, preview, and editor URLs. This may consume account credits.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesWhat VULK should build. Include product goal, audience, visual direction, pages, interactions, and delivery constraints.
modelNoOptional VULK model ID. Omit to let VULK pick the best model allowed by the account.

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already indicate non-read-only and non-destructive with side effects. The description adds that it may consume credits, which is valuable beyond annotations. No contradictions.

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 action and outputs, no wasted words. Efficient and clear.

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

Completeness4/5

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

With no output schema, the description mentions returned URLs and credit consumption. Parameter details are in schema. Could differentiate from siblings, but overall complete for tool usage.

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 both parameters described. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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 creates a VULK project from a prompt and returns URLs. It uses a specific verb and resource, but does not differentiate from siblings like create_visual_brief.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool vs alternatives. It implies use for project creation from a prompt and warns about credit consumption, but lacks exclusions or comparisons.

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

create_visual_briefCreate Visual BriefA
Read-onlyIdempotent
Inspect

Turn a raw idea into a concise production brief for an immersive VULK project. This does not create a project or call external services.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesWhat VULK should build. Include product goal, audience, visual direction, pages, interactions, and delivery constraints.
sourceNoPrimary input type behind the request.
moodboardNoOptional visual references, URLs, brand notes, colors, materials, motion references, or inspiration labels.
deliveryTargetNoOutput format VULK should optimize for.

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it does not call external services, which is consistent but does not elaborate on internal behavior (e.g., whether it saves state). Given annotation coverage, this is adequate but not exceptional.

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 two sentences with no redundancy. The first sentence states the core purpose, and the second clarifies boundaries. Every word contributes value.

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

Completeness4/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 (4 params, no output schema, no nested objects), the description covers purpose and scope adequately. It lacks details about the format of the generated brief or what the tool returns, but with good schema and annotations, this is a minor gap. Slightly better than the bare minimum.

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 clear descriptions for all four parameters. The description does not add any parameter-specific guidance beyond the implicit reference to 'raw idea' in the prompt. Baseline of 3 is appropriate since the schema handles parameter semantics.

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 uses a specific verb ('turn') and resource ('raw idea' into 'production brief'), and explicitly distinguishes from siblings by stating 'This does not create a project or call external services.' This clearly differentiates it from create_project and other generation tools.

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

Usage Guidelines4/5

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

The description indicates when to use (to generate a production brief) and what it does not do (create a project or call external services), providing implicit guidance against using it for full project creation. However, it does not explicitly name alternative tools or state when not to use.

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

deployDeploy VULK Project (Legacy)C
Destructive
Inspect

Legacy alias for deploy_project.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectIdYesVULK project ID.

TDQS

C2.3/5.0
Behavior2/5

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

Annotations already indicate destructiveHint=true. Description adds no additional behavioral context about the alias (e.g., whether behavior is identical to deploy_project).

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

Conciseness3/5

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

Extremely short, but concise. Lacks structure or elaboration, which reduces usefulness despite brevity.

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

Completeness2/5

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

Given the presence of deploy_project as a sibling, this alias needs to clarify its exact behavior or deprecation status. The description is too minimal for a tool with destructive behavior and no output schema.

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?

Input schema fully describes projectId with 100% coverage. Description adds nothing beyond schema, so baseline 3 is appropriate.

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

Purpose2/5

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

Description only states it is a legacy alias for deploy_project, but does not explicitly state what the tool does (e.g., deploy a project). This is almost a tautology of the title.

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

Usage Guidelines2/5

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

No context on when to use this alias versus deploy_project or other siblings. Only implies it is legacy, but no explicit guidance.

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

deploy_projectDeploy VULK ProjectA
Destructive
Inspect

Deploy a VULK project to production and return the production URL. Requires an eligible VULK plan.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectIdYesVULK project ID.

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already mark destructiveHint: true and readOnlyHint: false, so the description adds minimal extra behavioral context beyond stating it returns a URL, which is useful but not substantial.

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 concise sentences with no unnecessary words, front-loading the purpose and then adding the requirement.

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?

For a simple tool with one parameter, the description adequately covers the purpose, requirement, and return value, meeting the needs of an AI agent.

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 a clear description of 'projectId'; the description does not add additional meaning beyond the schema.

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 'Deploy a VULK project to production and return the production URL,' specifying the verb and resource, and distinguishing it from sibling tools like 'create_project' or the generic 'deploy'.

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

Usage Guidelines4/5

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

It includes a prerequisite ('Requires an eligible VULK plan'), offering clear guidance on when to use, but lacks explicit when-not-to-use or alternatives.

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

editEdit VULK Project (Legacy)C
Destructive
Inspect

Legacy alias for edit_project.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectIdYesVULK project ID to edit.
instructionYesNatural language instruction describing the exact change.

TDQS

C2.2/5.0
Behavior2/5

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

Annotations already indicate destructiveHint=true, but the description adds no behavioral context (e.g., what gets edited or consequences). Minimal value beyond annotations.

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

Conciseness2/5

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

Very short but fails to convey essential information. Not front-loaded with useful content; the single sentence is too sparse to be helpful.

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

Completeness2/5

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

Given the simplicity (alias tool) and complete schema, the description is incomplete. It does not explain what the tool does or when to use it, leaving the agent underinformed.

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%, so the schema already documents both parameters. Description adds no new meaning beyond the literal schema.

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

Purpose2/5

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

Description says it's a legacy alias for edit_project, but does not state the actual function (e.g., what edit_project does). The purpose is only implied as a redirect, which is vague.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives. Simply states it's a legacy alias, without any context for selection.

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

edit_projectEdit VULK ProjectA
Destructive
Inspect

Apply a natural-language change to an existing VULK project. VULK updates relevant files and returns preview/editor URLs.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectIdYesVULK project ID to edit.
instructionYesNatural language instruction describing the exact change.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, so the description adds value by noting it updates files and returns preview/editor URLs, providing behavioral context beyond 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?

A single sentence that is front-loaded with the action and outcome, with no unnecessary words. Highly efficient.

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

Completeness4/5

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

For a 2-param tool with annotations and no output schema, the description covers the core behavior and return value. It does not elaborate on return format but is sufficient for basic understanding.

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%, so the schema already explains both parameters. The description adds no new semantic information beyond mentioning 'natural-language instruction', which aligns with the schema.

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 verb 'apply a natural-language change' to 'an existing VULK project', distinguishing it from siblings like create_project (new project) and deploy/deploy_project (different actions).

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

Usage Guidelines4/5

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

The description indicates the tool is for modifying existing projects via natural language, but it does not explicitly exclude alternatives or mention when not to use it. Context is clear but lacks exclusions.

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

filesGet VULK Project Files (Legacy)A
Read-onlyIdempotent
Inspect

Legacy alias for get_project_files. Content is omitted by default for safety.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectIdYesVULK project ID.
pathsNoOptional exact project-relative file paths to return.
includeContentNoWhen false, returns only the file manifest. When true, returns content with redaction and size limits.
maxBytesNoMaximum total file-content bytes returned when includeContent is true.

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds key behavioral context: it is an alias for get_project_files, and content is omitted by default for safety, which goes beyond what annotations provide.

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 a single sentence that is front-loaded with the tool's purpose ('Legacy alias...') and includes a safety detail. Every word is meaningful, no redundancy.

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

Completeness4/5

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

For a legacy alias tool, the description effectively communicates its role and a key behavioral trait (content omission by default). The schema and annotations cover the remaining details, so it is mostly complete.

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 parameters. The description does not add new parameter-level meaning beyond what is already in the schema, 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?

The description clearly states it is a 'Legacy alias for get_project_files', which is a specific verb-resource pair (getting VULK project files) and distinguishes it from other tools by indicating it is a legacy version of a sibling tool.

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

Usage Guidelines2/5

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

The description does not provide explicit guidance on when to use this tool versus alternatives. It mentions 'Legacy alias' but does not advise against using it or direct users to the primary tool.

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

generateGenerate VULK Project (Legacy)AInspect

Legacy alias for create_project. Prefer create_project or generate_immersive_site in new clients.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesWhat VULK should build. Include product goal, audience, visual direction, pages, interactions, and delivery constraints.
modelNoOptional VULK model ID. Omit to let VULK pick the best model allowed by the account.

TDQS

A4/5.0
Behavior3/5

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

Annotations already provide safety hints (non-readonly, non-destructive). The description adds the behavioral trait of being a legacy alias, which is useful for deprecation awareness. However, no additional details about side effects, permissions, or response format are given, relying on the underlying create_project behavior.

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 a single sentence that is direct and non-redundant. Every word serves a purpose, making it highly efficient for an AI agent to parse.

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

Completeness4/5

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

For a legacy alias tool, the description adequately communicates its deprecation status and directs to alternatives. It does not explain return values or behavior in detail, but as an alias, that is acceptable. A reference to the create_project description could improve completeness.

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?

The input schema has 100% description coverage, so the schema already fully describes the parameters. The description adds no extra meaning to the parameters, earning the baseline score of 3.

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 identifies the tool as a legacy alias for create_project, specifying its purpose of generating a VULK project. It distinguishes from siblings by naming preferred alternatives, but could be more explicit about what the tool does beyond being an alias.

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?

Excellent guidance: explicitly states that it is a legacy alias and advises to prefer create_project or generate_immersive_site in new clients. This directly helps the agent decide when not to use this tool and which alternatives to choose.

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

generate_immersive_siteGenerate Immersive SiteAInspect

Generate a 3D, motion-rich, cinematic VULK web experience from a prompt, visual reference, URL, Figma, screenshot, video reference, or moodboard. Returns delivery URLs, not raw media assets.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesWhat VULK should build. Include product goal, audience, visual direction, pages, interactions, and delivery constraints.
sourceNoPrimary input type behind the request.
moodboardNoOptional visual references, URLs, brand notes, colors, materials, motion references, or inspiration labels.
deliveryTargetNoOutput format VULK should optimize for.
modelNoOptional VULK model ID. Omit to let VULK pick the best model allowed by the account.

TDQS

A4.1/5.0
Behavior4/5

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

Annotations indicate non-read-only and non-destructive. The description adds that it returns delivery URLs, not raw assets, providing useful behavioral context beyond 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 the core action, no wasted words. Very concise and structured.

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 5 parameters and no output schema, the description explains the output format (delivery URLs) but does not cover lifecycle aspects like whether it deploys or saves. Adequate but could be more complete.

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 baseline is 3. The description does not add additional meaning beyond what is already in the parameter descriptions.

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 it generates a 3D, motion-rich, cinematic VULK web experience from various inputs. The tool name and description are specific and distinct from siblings like 'create_project' or 'generate'.

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

Usage Guidelines4/5

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

The description lists input types and that it returns delivery URLs, giving clear context for when to use it. However, it does not explicitly compare with alternatives or state when not to use it.

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

getGet VULK Project (Legacy)B
Read-onlyIdempotent
Inspect

Legacy alias for get_project.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectIdYesVULK project ID.

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds the 'legacy alias' context, implying possible deprecation. It does not add further behavioral details beyond 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.

Conciseness4/5

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

Extremely concise – one phrase that clearly communicates the tool's nature as a legacy alias. No wasted words, but could include a note to prefer the newer tool.

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 low complexity (1 param, rich annotations, no output schema), the description is minimally adequate. It tells the agent it is a legacy alias, but lacks details about when to use or behaviors.

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 a clear parameter description. The tool description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.

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 it is a legacy alias for get_project, and the title already indicates 'Get VULK Project', so the purpose is understood. It identifies the specific verb-resource mapping.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus the primary get_project tool. It does not mention deprecation or preference, leaving the agent without usage context.

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

get_projectGet VULK ProjectA
Read-onlyIdempotent
Inspect

Get metadata, preview URL, and editor URL for one VULK project.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectIdYesVULK project ID.

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds the specific return fields (metadata, preview URL, editor URL) but does not disclose any additional behavioral traits beyond what annotations cover.

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 a single, concise sentence (11 words) that is front-loaded with purpose. No unnecessary words or redundancy.

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

Completeness4/5

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

Given the simplicity of the tool (one parameter, no output schema), the description adequately informs the agent that the response includes metadata, preview URL, and editor URL. It is complete enough for effective usage, though a slightly more detailed list could help.

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?

The input schema has 100% coverage for 'projectId' with a clear description ('VULK project ID.'). The tool description does not add extra meaning beyond the schema, so baseline 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 retrieves metadata, preview URL, and editor URL for a single VULK project. It uses a specific verb ('Get') and resource ('one VULK project'), distinguishing it from sibling tools like 'list_projects' or 'create_project'.

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 for retrieving a specific project but does not explicitly state when to use this tool versus alternatives like 'get_project_files' or 'list_projects'. No when-not or comparative guidance is provided.

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

get_project_filesGet VULK Project FilesA
Read-onlyIdempotent
Inspect

Return a project's file manifest. File content is omitted by default and, when requested, is redacted and size-limited.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectIdYesVULK project ID.
pathsNoOptional exact project-relative file paths to return.
includeContentNoWhen false, returns only the file manifest. When true, returns content with redaction and size limits.
maxBytesNoMaximum total file-content bytes returned when includeContent is true.

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds that content is omitted by default and redacted/size-limited when included, which is useful but not extensive. It does not disclose what 'redacted' entails or the return format for the manifest.

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 with two sentences that front-load the main purpose and key behavioral switch. No word is wasted, and it efficiently conveys the essential information.

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

Completeness4/5

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

Despite no output schema, the description is largely complete for a manifest retrieval tool. It covers the core purpose and the content inclusion option. However, it lacks details on what the manifest contains (e.g., file paths, metadata) and does not address error cases or limits on file count, which could affect agent decision-making.

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 clear parameter descriptions. The description does not add new semantic insight beyond summarizing default behavior already captured in the schema. It meets the baseline for a well-documented schema.

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 returns a project's file manifest and distinguishes between default behavior (manifest only) and optional content inclusion with redaction and size limits. The verb 'Return' and resource 'project's file manifest' are specific, and the description differentiates it from siblings like 'list' or 'files' by specifying project-scoped file retrieval.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, edge cases, or situations where a different tool (e.g., 'files' or 'get') would be more appropriate. An explicit usage context is missing.

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

get_usageGet VULK UsageA
Read-onlyIdempotent
Inspect

Check API usage, credits, and rate-limit status for the authenticated VULK account.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. Description adds what specific data is checked (usage, credits, rate-limit status), providing context beyond annotations. No contradiction.

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?

Single sentence with no wasted words. Front-loaded with the core action. Efficient and clear.

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?

While simple, the tool has no output schema and description only lists what is checked. Missing details like data format or pagination, but openWorldHint suggests response is self-explanatory. Adequate but incomplete.

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

Parameters4/5

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

No parameters exist, so schema coverage is 100%. Description does not need to add param info; baseline score of 4 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?

Description clearly states the tool checks API usage, credits, and rate-limit status. Verb 'Check' and specific resources prevent ambiguity. Distinguishes from sibling 'usage' by specifying 'for the authenticated VULK account'.

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?

Description implies the tool is for checking usage status, but does not explicitly state when to use it over other tools or when not to use it. No alternatives are mentioned.

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

listList VULK Projects (Legacy)B
Read-onlyIdempotent
Inspect

Legacy alias for list_projects.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of projects to return. Defaults to 20.
offsetNoNumber of projects to skip for pagination.

TDQS

B3.3/5.0
Behavior2/5

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

Annotations already indicate readOnly, non-destructive, idempotent, open world. The description adds no behavioral insights beyond this.

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?

Single sentence, no unnecessary words, efficiently communicates that this is a legacy alias.

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?

The description is minimal but sufficient for a legacy alias since the behavior is defined by the primary tool list_projects. However, it lacks details on output format.

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 covers all parameters with descriptions (100% coverage), so description adds no additional parameter semantics.

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 states it lists VULK projects and is a legacy alias for list_projects, making the purpose clear but not providing additional details beyond the title.

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 that list_projects is the preferred tool by labeling 'list' as legacy, but does not explicitly state when to use which.

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

list_modelsList VULK ModelsA
Read-onlyIdempotent
Inspect

List AI models available to the authenticated VULK account.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint. Description adds only the authentication scope. Lacks details on return format or pagination, which are not critical given no params and good 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?

Single, clear sentence with no unnecessary words. Front-loaded with purpose.

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?

Given no parameters, no output schema, and read-only annotations, the description fully covers what the agent needs: a state-query tool listing models for the current user.

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

Parameters4/5

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

No parameters exist, so schema coverage is 100%. Description adds nothing beyond schema, but baseline for 0 params is 4.

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?

Clear verb 'List' with specific resource 'AI models' and scope 'available to the authenticated VULK account'. Differentiates from sibling 'list_projects' by specifying models.

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?

No guidance on when to use this tool versus alternatives like 'models' or 'list'. For a simple list tool, minimal guidance is acceptable, but no exclusions or context provided.

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

list_projectsList VULK ProjectsB
Read-onlyIdempotent
Inspect

List VULK projects visible to the authenticated account.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of projects to return. Defaults to 20.
offsetNoNumber of projects to skip for pagination.

TDQS

B3.3/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description adds little beyond stating authentication visibility. The description does not disclose any additional behavioral traits like rate limiting, response size limits, or sorting behavior.

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 a single sentence with no redundant information. It is front-loaded and efficient.

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 simplicity and high schema coverage, the description is adequate but lacks guidance on ordering, sorting, or alternatives among sibling list tools. It does not cover return behavior or next steps.

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 clear definitions for limit and offset including defaults and bounds. The description does not add any extra semantic meaning beyond the schema, so 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 'List VULK projects visible to the authenticated account', specifying the verb (list), resource (projects), and scope (visible to account). It distinguishes from siblings like get_project (single) and list_models (different resource).

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives like list_models or get_project. There is no mention of pagination strategies, nor exclusions for certain scenarios. The description provides no usage context beyond the bare function.

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

modelsList VULK Models (Legacy)A
Read-onlyIdempotent
Inspect

Legacy alias for list_models.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior2/5

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds no behavioral context beyond 'Legacy alias,' missing details such as return format or pagination behavior.

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 a single sentence, extremely concise, and contains no unnecessary words. It earns its place by clearly stating the tool's nature as a legacy alias.

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

Completeness2/5

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

Given it is a legacy alias, the description does not explain what the tool returns or how it behaves, relying entirely on the sibling 'list_models' for complete context. For a tool with no output schema, this is insufficient.

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

Parameters4/5

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

The input schema has zero parameters with 100% coverage, so the description adds no parameter info. Per guidelines, with 0 parameters, the baseline score is 4.

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 states 'Legacy alias for list_models,' which clearly identifies the tool as a deprecated synonym for listing models. It distinguishes from the sibling 'list_models' but lacks explicit mention of what 'models' are.

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 states it is a 'Legacy alias for list_models,' strongly guiding the agent to use the sibling tool 'list_models' instead for current usage.

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

subscribeOpen VULK BillingA
Read-onlyIdempotent
Inspect

Return a VULK pricing or checkout URL. This does not change billing by itself.

ParametersJSON Schema
NameRequiredDescriptionDefault
planNoPlan to open. If omitted, returns the pricing page.

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by explicitly stating it returns a URL and does not change billing, which aligns with annotations and provides beyond-what-is-annotated context.

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 concise sentences, no fluff, front-loaded with the core purpose. Every word earns its place.

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?

Given low complexity (1 optional param, no output schema), the description fully covers the tool's behavior: it returns a URL, does not change billing, and implies no side effects. No 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?

The input schema has 100% coverage, with the 'plan' parameter fully described via enum values. The description does not add additional meaning to parameters beyond the schema, so 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 it returns a VULK pricing or checkout URL, with a specific verb ('Return') and resource ('VULK pricing or checkout URL'). It distinguishes itself from sibling tools like create_project or deploy by emphasizing it's a read-only action returning a URL.

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 by noting it does not change billing, suggesting it's for retrieving a URL rather than modifying subscriptions. However, it lacks explicit when-to-use or when-not-to-use guidance compared to alternatives.

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

usageGet VULK Usage (Legacy)A
Read-onlyIdempotent
Inspect

Legacy alias for get_usage.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, etc., so the description adds no new behavioral info beyond being an alias. It does not contradict annotations, but fails to disclose any additional traits like return format or scope.

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?

Single sentence with no wasted words. It efficiently conveys the tool's purpose and relationship to a sibling. Perfectly concise for a simple alias.

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 no parameters, no output schema, and annotations covering safety, the description is partially complete. However, it relies entirely on the sibling 'get_usage' for details on return values and behavior, leaving ambiguity for agents without access to that tool's description.

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

Parameters4/5

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

With no parameters (schema coverage 100%), the description cannot add parameter meaning. Baseline 4 is appropriate as the schema already fully documents parameters (none exist).

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 'Legacy alias for get_usage' combined with the title 'Get VULK Usage (Legacy)' clearly indicates the tool is a read-only wrapper for usage data, and distinguishes it from the sibling 'get_usage' by noting its legacy status.

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 that 'get_usage' is the modern equivalent, but does not explicitly state when to prefer this alias or provide exclusion criteria. The legacy label gives some context, but lacks direct guidance on usage scenarios.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 19 tool updatesv1.1.0
    • Addedcreate_project
    • Addedcreate_visual_brief
    • Changeddeploy4 fields changed
      • changedInput schema / properties / projectId / description
        Previous value: -"Project ID to deploy"New value: +"VULK project ID."
      • addedInput schema / properties / projectId / maxLength
        Added value: +128
      • addedInput schema / properties / projectId / minLength
        Added value: +8
      • addedInput schema / properties / projectId / pattern
        Added value: +"^[A-Za-z0-9_-]+$"
    • Addeddeploy_project
    • Changededit7 fields changed
      • changedInput schema / properties / instruction / description
        Previous value: -"What to change. Be specific. Example: 'Add a settings page with tabs for Profile, Billing, and Notifications. Include form validation and a save button with loading state.'"New value: +"Natural language instruction describing the exact change."
      • addedInput schema / properties / instruction / maxLength
        Added value: +12000
      • addedInput schema / properties / instruction / minLength
        Added value: +5
      • changedInput schema / properties / projectId / description
        Previous value: -"Project ID to edit"New value: +"VULK project ID to edit."
      • addedInput schema / properties / projectId / maxLength
        Added value: +128
      • addedInput schema / properties / projectId / minLength
        Added value: +8
      • addedInput schema / properties / projectId / pattern
        Added value: +"^[A-Za-z0-9_-]+$"
    • Addededit_project
    • Changedfiles7 fields changed
      • addedInput schema / properties / includeContent
        Added value: +{
+  "default": false,
+  "description": "When false, returns only the file manifest. When true, returns content with redaction and size limits.",
+  "type": "boolean"
+}
      • addedInput schema / properties / maxBytes
        Added value: +{
+  "default": 50000,
+  "description": "Maximum total file-content bytes returned when includeContent is true.",
+  "maximum": 200000,
+  "minimum": 1000,
+  "type": "integer"
+}
      • addedInput schema / properties / paths
        Added value: +{
+  "description": "Optional exact project-relative file paths to return.",
+  "items": {
+    "maxLength": 512,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 50,
+  "type": "array"
+}
      • changedInput schema / properties / projectId / description
        Previous value: -"Project ID"New value: +"VULK project ID."
      • addedInput schema / properties / projectId / maxLength
        Added value: +128
      • addedInput schema / properties / projectId / minLength
        Added value: +8
      • addedInput schema / properties / projectId / pattern
        Added value: +"^[A-Za-z0-9_-]+$"
    • Changedgenerate6 fields changed
      • changedInput schema / properties / model / description
        Previous value: -"AI model to use. Options include: 'claude-sonnet-4-20250514' (default, best quality), 'gpt-4o' (fast), 'gemini-2.5-pro' (creative), 'deepseek-chat' (budget). Leave empty for the best model available on your plan."New value: +"Optional VULK model ID. Omit to let VULK pick the best model allowed by the account."
      • addedInput schema / properties / model / maxLength
        Added value: +160
      • addedInput schema / properties / model / minLength
        Added value: +1
      • changedInput schema / properties / prompt / description
        Previous value: -"Detailed description of the app to build. Be specific about features, pages, design style, and functionality. More detail = better results. Example: 'A modern project management app like Linear with kanban boards, sprint planning, team member assignments, dark mode, and real-time updates'"New value: +"What VULK should build. Include product goal, audience, visual direction, pages, interactions, and delivery constraints."
      • addedInput schema / properties / prompt / maxLength
        Added value: +20000
      • addedInput schema / properties / prompt / minLength
        Added value: +10
    • Addedgenerate_immersive_site
    • Changedget4 fields changed
      • changedInput schema / properties / projectId / description
        Previous value: -"Project ID"New value: +"VULK project ID."
      • addedInput schema / properties / projectId / maxLength
        Added value: +128
      • addedInput schema / properties / projectId / minLength
        Added value: +8
      • addedInput schema / properties / projectId / pattern
        Added value: +"^[A-Za-z0-9_-]+$"
    • Addedget_project
    • Addedget_project_files
    • Addedget_usage
    • Changedlist4 fields changed
      • changedInput schema / properties / limit / description
        Previous value: -"Number of projects (1-100, default 20)"New value: +"Number of projects to return. Defaults to 20."
      • changedInput schema / properties / limit / type
        Previous value: -"number"New value: +"integer"
      • changedInput schema / properties / offset / description
        Previous value: -"Skip N projects (for pagination)"New value: +"Number of projects to skip for pagination."
      • changedInput schema / properties / offset / type
        Previous value: -"number"New value: +"integer"
    • Addedlist_models
    • Addedlist_projects
    • Changedmodels1 field changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
    • Changedsubscribe1 field changed
      • changedInput schema / properties / plan / description
        Previous value: -"Plan to subscribe to. Opens pricing page if omitted."New value: +"Plan to open. If omitted, returns the pricing page."
    • Changedusage1 field changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
  2. 9 tool updatesv1.0.1
    • First observeddeploy
    • First observededit
    • First observedfiles
    • First observedgenerate
    • First observedget
    • First observedlist
    • First observedmodels
    • First observedsubscribe
    • First observedusage
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.8/5.0
Disambiguation2/5

Many legacy aliases (e.g., deploy, edit, generate) duplicate primary tools, creating confusion about which to use. Tools like create_project and generate_immersive_site have overlapping purposes, and agents may struggle to choose correctly.

Naming Consistency2/5

Primary tools use snake_case (create_project, deploy_project), but legacy aliases are single words (deploy, edit, list). This inconsistent naming pattern (camelCase is absent, but mixing verb forms and lengths) reduces predictability.

Tool Count3/5

With 19 tools, many are redundant aliases. The core set of about 11 unique tools is reasonable for project creation and deployment, but the extra aliases make the count feel bloated for the actual scope.

Completeness3/5

CRUD-like operations are partially covered: create, read, update (via edit), list. However, delete is missing, and there is no direct tool to update project metadata (only file edits). Billing is limited to a pricing URL. Notable gaps exist.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

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/VULK-dev/vulk-mcp-server'

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