Skip to main content
Glama

validate_app

Read-only

Checks an app (html or zipBase64) against noback's rules, with the limits of an app without an account, without publishing anything or running its code. Use it before create_app or update_app. Returns { ok, errors, warnings }; each item has a code, a message and a fix. Fix every error before publishing; warnings are suggestions and the app works anyway. Without an account, the app can reach the internet only through the services on noback's list. If warnings include NO_APP_DB with certain: true, the app loses what people enter when the page reloads: save it in localStorage (the warning's prompt says what to change) before publishing. If warnings include STATIC_LIST, the content is written by hand in the page: offer to make it editable from the page, with only the owner writing (the warning's prompt says what to ask for). Read-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "validate_app"
  }
}

Input Schema

NameRequiredDescriptionDefault
htmlNoThe complete contents of ONE HTML file, with its CSS and JS inline. Don't add the noback SDK by hand: noback injects window.app. Send html or zipBase64, not both.
zipBase64NoA complete .zip package encoded in base64, instead of html: index.html at the root, an optional noback.toml, plus scripts, styles and files. Send html or zipBase64, not both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / html / description
      Previous value: -"Contenido completo de UN archivo HTML; CSS y JS inline, sin SDK manual."New value: +"The complete contents of ONE HTML file, with its CSS and JS inline. Don't add the noback SDK by hand: noback injects window.app. Send html or zipBase64, not both."
    • changedInput schema / properties / zipBase64 / description
      Previous value: -"Paquete .zip completo en base64, en lugar de html. index.html en la raíz; noback.toml opcional."New value: +"A complete .zip package encoded in base64, instead of html: index.html at the root, an optional noback.toml, plus scripts, styles and files. Send html or zipBase64, not both."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint/destructiveHint annotations, it discloses behavior the annotations cannot: nothing is published, the app's code is not executed, and without an account the app's network reach is limited to noback's service list. It also explains what specific warnings mean operationally (NO_APP_DB with certain:true means user input is lost on reload; STATIC_LIST means hand-written content), which is real behavioral context. The trailing 'Read-only.' does restate the annotation, but it is a single clause and not a contradiction.

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?

Front-loaded correctly: purpose, then when-to-use, then return shape, then remediation rules. Four-plus sentences of remediation detail (localStorage for NO_APP_DB, ownership for STATIC_LIST) is on the long side for a validator and pushes toward create_app's territory, but each clause is actionable rather than padding.

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?

No output schema exists, yet the description specifies the return shape ({ ok, errors, warnings }) and the per-item structure (code, message, fix), plus the severity semantics distinguishing errors from warnings. Combined with full schema coverage for both inputs, an agent has everything needed to call it and interpret results.

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% and both parameters are fully documented in the schema, including the mutual exclusion 'Send html or zipBase64, not both.' The description only echoes the param names parenthetically. Baseline 3 applies — the schema, not the description, carries parameter meaning.

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?

Opens with a specific verb and resource: 'Checks an app (html or zipBase64) against noback's rules,' and immediately bounds the scope — no publishing, no code execution, account-less limits. An agent can distinguish it from create_app/update_app/get_sdk without opening any schema.

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 routes the agent: 'Use it before create_app or update_app,' and names the two siblings it precedes. It also gives a decision rule for the output ('Fix every error before publishing; warnings are suggestions'), which is exactly the when-to-act guidance an agent needs.

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