Skip to main content
Glama

Quillm

by ai.quillm
OverviewDiscussionsAdmin

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. If the request does not say who reads the page, what for, and which number matters most, ask the user first; when the brief is thin, the response suggests the questions 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
iconNoOptional. One emoji for the page, e.g. "💰". The app shows a glyph for the page's kind when there is none.
kindYesWhat 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.
slugYesURL id, lowercase-with-dashes, e.g. "finance-overview". Permanent.
briefYesThe 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.
coverNoOptional and no longer shown; kept for older clients.
titleYesShown in the app's sidebar.
sourceYesThe full single-file React source (JSX/TSX) with a default-exported component. See get_guide.
questionsYesWrite 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.
collectionYesSidebar 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_noteNoWhy this view was created (recorded in the changelog).
descriptionYesOne sentence: what this view answers. Other agents use it to decide whether to reuse this view.
dependenciesNoOnly for npm packages outside the base runtime, with exact versions: {"d3-sankey": "0.12.3"}.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only give the generic mutating/openWorld profile; the description adds that the view is compiled, test-rendered in a real browser and reviewed immediately, what the response contains (render status, errors, missing reader context), and that two external services (TypeSafe, OpenAI) receive the brief and a screenshot unless the workspace disables them — a substantive, non-obvious disclosure.

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 and dense with actionable content, but it is long and a few statements restate schema text (e.g. the brief's 'request plus what you asked and what they answered' is already documented in the brief schema), which slightly dilutes an otherwise well-ordered flow.

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, and the description compensates by explaining what the response reports (render success, errors, gaps a reader would notice), plus prerequisites, the sequence of dependent tools, and the external-service/privacy consideration — everything needed to invoke this complex 12-parameter tool correctly.

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 adds genuine meaning: source must be ONE file default-exporting a component, brief must quote the user rather than paraphrase into a plan, and questions define the page's scope so each block answers one question once.

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 with concrete scope: 'Creates a new view: a live page at a stable URL in the user's dashboard app.' It goes further to define the artifact (single-file React component reading useDataset) and explicitly distinguishes itself from siblings create_dataset and update_view.

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 routing and ordering rules: create the dataset first via create_dataset, call get_guide first for the template, check get_workspace first and use update_view if a suitable view exists. Also states when to ask the user before building rather than proceeding.

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

All Quillm toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources