Dashly

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

TableJSON Schema

Name	Required	Description
`goal`	No	An 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.
`name`	Yes	What the person calls it, e.g. "Water" or "Morning run". Up to 80 characters.
`type`	Yes	How 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).
`unit`	No	The 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.
`color`	No	The 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.
`scale`	No	A 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.
`fields`	No	Extra 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.
`visual`	No	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.
`polarity`	No	build (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.
`statuses`	No	Task topics only: the statuses a task moves through, in order. At least one must be terminal (done). Defaults to To do, Doing, Done.
`unitLabel`	No	How the unit reads aloud, e.g. "millilitres". Defaults to the unit.
`description`	No	One optional sentence about what is tracked. Up to 500 characters.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`topic`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 18, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false) already establish that this is a non-destructive local write, and the description is consistent with that. It adds genuinely useful side-effect context beyond the annotations: a new topic's tile appears on home automatically and elsewhere only after a card is added, which an agent would otherwise not know.

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?

The description is four front-loaded sentences: purpose, placement side effect, reuse workflow, then type/unit rules. Nothing is padded, though the type enumeration duplicates the schema enum and could have been left to the structured field.

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 nested tool with an output schema, the description supplies the purpose, the reuse-first workflow, the placement behavior, and the unit discipline, while the schema handles all validation details. It is complete enough to call correctly, with the only gap being an explicit pointer to update_topic/archive_topic for existing topics.

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 every one of the 12 parameters carries a rich inline description, so the schema does the heavy lifting. The description's type list largely restates the type enum, and its only extra guidance ('Pick one unit and keep every value in it') is a durable logging rule rather than call-time parameter meaning, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a concrete verb ('Creates') and elaborates the resource into a full taxonomy of trackable types, so an agent knows exactly what is being instantiated. It partially differentiates from siblings by naming list_topics and update_dashboard, but never states plainly that the output is a 'topic', leaving the object identity implicit rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'List topics first and reuse a matching one' is explicit, actionable pre-call guidance, and the dashboard-placement sentence clarifies when a separate update_dashboard step is required. There is no when-not guidance (e.g. use update_topic to modify an existing topic instead), so it stops short of full routing coverage.

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

All Dashly 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.

Resources

Need Help?