Quillm

Create a view

create_view

Creates a new view: a live page at a stable URL in the user's dashboard app. source is ONE file of React (JSX/TSX) that default-exports a component and reads its data with useDataset("dataset_name") from "quillm". Do not embed data in the source; create the dataset first (create_dataset), then the view. Pass the brief: the user's request in their words, and what you asked them and what they answered. When the brief is thin, the response suggests what to ask. Decide the questions next: what the user asked for is the scope, and a small request gets a small page. The view is compiled, test-rendered in a real browser and reviewed immediately: the response tells you whether it rendered, lists errors, and lists what a reader would still be missing, so read it and fix problems with update_view. The checks use two outside services unless the workspace turned them off: TypeSafe reads the brief, and OpenAI reads a screenshot and the page's text. Call get_guide first for the template and available libraries. Check get_workspace first: if a suitable view already exists, use update_view instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>",
      "title": "<title>",
      "description": "<description>",
      "collection": "<collection>",
      "kind": "<kind>",
      "brief": "<brief>",
      "questions": "<questions>",
      "source": "<source>"
    },
    "name": "create_view"
  }
}

Input Schema

Name	Required	Description
`icon`	No	Optional. One emoji for the page, e.g. "💰". The app shows a glyph for the page's kind when there is none.
`kind`	Yes	What the page is for. "dashboard": numbers someone watches over time. "tracker": items people work through (steps, tasks, leads) with owners and status. "doc": a brief, report or analysis mostly in prose. "calculator": inputs the reader changes and an answer. Decides what the page review holds it to.
`slug`	Yes	URL id, lowercase-with-dashes, e.g. "finance-overview". Permanent.
`brief`	Yes	The brief. Quillm judges whether it is enough to build a page someone will read for months; when it is not, create_view still builds the page and tells you what to ask the user.
`cover`	No	Optional and no longer shown; kept for older clients.
`title`	Yes	Shown in the app's sidebar.
`source`	Yes	The full single-file React source (JSX/TSX) with a default-exported component. See get_guide.
`questions`	Yes	Write these BEFORE the source. The 1-5 questions the user has in mind when they open this page, in their words: "How many months of cash do we have?", "Who do I need to follow up with today?". What the user asked for is the scope: every block in the view answers one of these, once.
`collection`	Yes	Sidebar group, e.g. "Finance", "Growth", "Projects". Reuse an existing collection when one fits. People are given access per collection, so the collection decides who can open the view; do not move a view to another collection unless asked.
`change_note`	No	Why this view was created (recorded in the changelog).
`description`	Yes	One sentence: what this view answers. Other agents use it to decide whether to reuse this view.
`dependencies`	No	Only for npm packages outside the base runtime, with exact versions: {"d3-sankey": "0.12.3"}.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 5, 2026

changedInput schema / properties / brief / description

Previous value: -"The brief. Quillm judges whether it is enough to build a page someone will read for months; when it is not, create_view refuses once and tells you what to ask the user."New value: +"The brief. Quillm judges whether it is enough to build a page someone will read for months; when it is not, create_view still builds the page and tells you what to ask the user."

First observedOct 3, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare the generic profile (readOnlyHint=false, openWorldHint=true, non-idempotent, non-destructive); the description adds what actually happens on call — the source is compiled, test-rendered in a real browser, and reviewed, and the response reports render status, errors, and content gaps. It also discloses that checks send data to two outside services (TypeSafe reads the brief, OpenAI reads a screenshot and page text) unless the workspace disabled them, which is material context an agent would not otherwise have.

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 with what the tool creates, then prerequisites, then what comes back, then the get_guide/get_workspace routing. Every sentence carries information, but it is dense and long for a single description, with the get_guide and get_workspace instructions split across the start and end rather than consolidated.

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 12-parameter, 8-required, nested-object tool with no output schema, the description covers the missing pieces: it says what the response contains (rendered or not, errors, missing reader content) and warns that the first call may come back needing fixes. Combined with the schema's own field documentation, an agent has enough to invoke this correctly on the first try.

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 the baseline is 3, but the description goes beyond it: `source` must be ONE file of React default-exporting a component that reads data via useDataset(...) and must not embed data, and `brief`/`questions` are explained in terms of what to write and in what order ('Decide the questions next... a small request gets a small page'). It adds real authoring semantics, though it does not touch every parameter (collection, kind, dependencies 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 and resource ('Creates a new view: a live page at a stable URL in the user's dashboard app') and immediately defines what a view actually is. It distinguishes the create path from update_view and from create_dataset in the same paragraph, so an agent can route correctly 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?

Gives an explicit ordering and a branching condition: create the dataset first via create_dataset, call get_guide first for the template, and 'Check get_workspace first: if a suitable view already exists, use update_view instead.' It also names the follow-up path ('fix problems with update_view'), covering when-not-to-use as well as when-to-use.

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

All Quillm tools Inspect

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.