Skip to main content
Glama
Sign In

Raziel

by io.github.tide-foundation
OverviewDiscussionsAdmin

tide_scaffold

Read-only

START A NEW TIDE APP FROM A WORKING TEMPLATE. Returns the exact commands to copy a complete, building app — login, the DPoP page and its wiring, server-side token AND proof verification, and the realm bootstrap script — then install, bootstrap and check it. CALL THIS when building a new app, BEFORE writing any auth code: the code that most often goes wrong (provider config, DPoP, route and API protection) is then copied, not retyped. Pass situation and it picks the template; or name one. Not for adding Tide to an existing app.

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": "tide_scaffold"
  }
}

Input Schema

NameRequiredDescriptionDefault
appDirNoDirectory to create the app in. Default: the current directory.
appNameNoLowercase name, e.g. 'mood-garden'. Becomes the package name, and so the realm and client names.
templateNoChoose a template explicitly instead of from `situation`.
situationNoWhat the user wants to build, in their words. Used to pick the template.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true/destructiveHint=false, and the description is consistent with that: the tool 'Returns the exact commands' rather than executing scaffolding or installing anything itself. It adds useful substance beyond the annotations by enumerating what the template contains (login, DPoP page and wiring, server-side token AND proof verification, realm bootstrap) and the install/bootstrap/check sequence, though it never states whether it writes to disk or what the returned command payload looks like in structure.

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 verb and resource in the first clause, with the call-this/when-not guidance at the end. Dense and mostly waste-free, though the all-caps clauses and the parenthetical triple ('provider config, DPoP, route and API protection') add rhetorical bulk.

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?

No output schema exists, and the description does tell the agent it receives exact shell commands plus an install/bootstrap/check flow, which is the essential return contract. Given 0 required parameters and full schema coverage, what remains missing is minor: whether files are created at `appDir` or merely printed, and how many templates/decisions the agent can defer to `situation`.

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?

Schema coverage is 100%, so baseline is 3, but the description adds real semantics the schema does not: 'Pass `situation` and it picks the template; or name one', which explains the precedence between the two template-selection parameters. `appDir` and `appName` are left to 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?

States a specific verb+resource: starts a new Tide app from a working template, and clarifies it returns the commands rather than the app itself. The closing sentence 'Not for adding Tide to an existing app' separates it from onboarding/adapter siblings that handle an existing codebase.

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?

Explicit when: 'CALL THIS when building a new app, BEFORE writing any auth code', with the rationale that provider config, DPoP and route/API protection get copied rather than retyped. Explicit when-not: 'Not for adding Tide to an existing app.' The one gap is that the alternative for the existing-app case is not named, but the exclusion itself is unambiguous.

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

All Raziel toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources