Skip to main content
Glama

Create a topic

create_topic

Creates something to track. Its tile appears on home by itself; it is on another dashboard only when you add a card for it there with update_dashboard. List topics first and reuse a matching one. Types: sum (amounts that add up in a day), measurement (latest reading of the day counts), count (how many times), duration (minutes), money (amounts in a currency), checkbox (done or not each day), event (things that happened, no number), task (to-dos with statuses). Pick one unit and keep every value in it.

Input Schema

NameRequiredDescriptionDefault
goalNoAn optional goal in the topic unit. Always set `direction`; Dashly never guesses it. at_least is a target to reach (water 2000 ml, protein 140 g, steps). at_most is a limit to stay under (calories 2000 kcal, spending 400 USD, drinks). between is a range with `min` and `max` (sleep 7 to 9 h). at_least and at_most take `value`. Give `per` (day, week, month or year) for a goal that repeats, or `by` (YYYY-MM-DD) for one that runs once until a date ("75 kg by 1 February": at_most 75, by 2027-02-01; "save 2,000 by June": at_least 2000, by the date). A dated goal on a reading is judged on its smoothed trend from the reading when it was set. `counts` is amount (the default) or days, for goals like "gym 3 days a week" (direction at_least, value 3, per week, counts days). If the person gives a number without saying whether it is a limit or a target, ask them.
nameYesWhat the person calls it, e.g. "Water" or "Morning run". Up to 80 characters.
typeYesHow entries behave. sum: amounts that add up through the day (water, calories). measurement: a reading where the latest of the day counts (weight, blood pressure). count: how many times (cigarettes, pushups); an entry with no value counts as 1. duration: time spent, always in minutes (unit "min"). money: spending or income in a currency. checkbox: done or not done for the day (habits). event: things that happened, with no number (headache, meeting). task: to-dos with a status. rating: a score on a scale the person chooses, averaged over the day (mood 1 to 5, energy, pain).
unitNoThe unit every value is stored in, e.g. "ml", "kg", "USD". Choose one unit and convert every value into it before logging. Required for sum, measurement and money; duration is always "min"; checkbox, event and task take none.
colorNoThe topic's own colour, one of: sky, blue, indigo, violet, fuchsia, pink, orange, teal, emerald, cyan, sand, silver. Leave it out and Dashly gives the next colour no other topic uses. Choose by meaning when one fits (sky for water, orange for food, indigo for sleep) and change it when the person asks.
scaleNoA scale { min, max, labels? } of whole steps, labels optional words for some of them ({ "1": "awful", "5": "great" }). Required for rating topics. On an event topic it lets each entry carry a severity (values.severity), e.g. a headache from 1 to 5.
fieldsNoExtra numeric fields kept beside the main value, e.g. protein and carbs on a meal. Only for sum and measurement topics, up to 20. Each has a lowercase key, a label, a unit and an optional goal shaped like the topic goal, so protein can be at_least while calories are at_most.
visualNoWhat the topic draws in its tile's level column everywhere (home, every dashboard, its page, the calendar), from the group its type, goal and polarity point to: a scene, a chart, or plain (no column, the number and its words across the whole tile). get_capabilities lists each group's visuals with what they show. Pick by meaning (a piggy bank for savings, a ring for a daily target, day bars for counting with no goal); use a chart or plain when the person wants a quieter, professional look; leave it out for the one that fits what it tracks. A visual from another group is refused with the ones that fit.
polarityNobuild (the default) for something the person wants more of or just tracks; avoid for something they want less of (headaches, panic attacks, cigarettes, takeaway). With avoid, a day with nothing logged is a good day, each entry counts against it, the streak is days without, and a goal can only be a limit (at_most). Set it whenever the topic is something to avoid; ask if unsure.
statusesNoTask topics only: the statuses a task moves through, in order. At least one must be terminal (done). Defaults to To do, Doing, Done.
unitLabelNoHow the unit reads aloud, e.g. "millilitres". Defaults to the unit.
descriptionNoOne optional sentence about what is tracked. Up to 500 characters.

Output Schema

NameRequiredDescriptionDefault
topicYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / visual / description
      Previous value: -"The scene the topic plays in its tile's level column everywhere (home, every dashboard, its page, the calendar), from the group its type, goal and polarity point to; get_capabilities lists each group's scenes with what they show. Pick by meaning (a piggy bank for savings, a balloon that pops for screen time); leave it out for the one that fits what it tracks. A scene from another group is refused with the ones that fit."New value: +"What the topic draws in its tile's level column everywhere (home, every dashboard, its page, the calendar), from the group its type, goal and polarity point to: a scene, a chart, or plain (no column, the number and its words across the whole tile). get_capabilities lists each group's visuals with what they show. Pick by meaning (a piggy bank for savings, a ring for a daily target, day bars for counting with no goal); use a chart or plain when the person wants a quieter, professional look; leave it out for the one that fits what it tracks. A visual from another group is refused with the ones that fit."
    • changedInput schema / properties / visual / enum
      Previous value: -[
      -  "climb",
      -  "building",
      -  "rocket",
      -  "piggy",
      -  "glass",
      -  "cups",
      -  "balloon",
      -  "hourglass",
      -  "boat",
      -  "cairn",
      -  "skyline",
      -  "hotair",
      -  "path",
      -  "weather",
      -  "gumball",
      -  "tray",
      -  "sun"
      -]New value: +[
      +  "climb",
      +  "building",
      +  "rocket",
      +  "piggy",
      +  "gauge",
      +  "ring",
      +  "dots",
      +  "macros",
      +  "plain",
      +  "glass",
      +  "cups",
      +  "balloon",
      +  "hourglass",
      +  "boat",
      +  "cairn",
      +  "grid",
      +  "skyline",
      +  "hotair",
      +  "path",
      +  "line",
      +  "ranges",
      +  "weather",
      +  "dial",
      +  "usual",
      +  "days",
      +  "gumball",
      +  "tray",
      +  "sun"
      +]
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare write semantics (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the bar is lower. The description adds real non-schema behavior: a new topic's tile lands on home by itself and appears elsewhere only via update_dashboard, colour is auto-assigned when omitted, and units must be normalized ('pick one unit and keep every value in it'). No permissions or failure modes are covered, hence not a 5.

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-loads the core action, then dedup guidance, then the type taxonomy. Most sentences earn their place, but the long inline type enumeration duplicates the enum's own descriptions and pushes the important 'list first' guidance into a mid-paragraph position.

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 12-parameter tool with nested oneOf goals and 20+ sibling tools, the description covers purpose, dedup workflow and cross-tool routing, and an output schema exists so return values need not be explained. It leaves the goal/scale/fields structure entirely to the schema, which is acceptable given 100% schema coverage.

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% and the property descriptions are extremely detailed (goal shapes, type semantics, unit rules, colour, polarity), so the schema already carries parameter meaning. The description largely restates this (its type list even omits 'rating'), so baseline 3 is correct.

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 concrete creation verb and resource ('Creates something to track', a topic) and immediately distinguishes it from siblings by naming list_topics (reuse) and update_dashboard (adding a card elsewhere). The full type taxonomy makes the artifact this produces unambiguous.

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 precondition/alternative: 'List topics first and reuse a matching one' tells the agent when not to call this tool. It also routes a related need (placing a tile on another dashboard) to update_dashboard, so the agent knows where the boundary of this tool lies.

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