Skip to main content
Glama

xtiles_create_notification

Destructive

Create a notification for the owner of the account you are working in, about work they did not watch happen. It appears in their own xTiles notification feed and, with the xTiles mobile app, as a push on their phone: there is no recipient parameter and nothing is sent to anyone else. WHEN: (1) a scheduled or recurring run, or a prepared workflow, whose instructions say to notify the person — no such line in its instructions, no notification; (2) the person explicitly asks to be told, reminded or notified; (3) you set up a schedule and the person agreed to be notified — one notification at the end of the setup. Never after an ordinary one-off request in a live conversation, and do not offer one there: the person is reading your reply and already has the links. When you set up a schedule, offer this notification together with it, and only with consent make "when everything is ready, send a notification titled ' is ready' for each place changed" the last step of the scheduled instructions. HOW: the very last calls of the turn, after all the work including layout and styling — nothing may change after them. Always with a title. Once per place you changed (a project page, a planner day), one notification covering everything done there — never once per task or tile. Two places changed means two calls, each with its own url and its own summary, even when the person asked for "a notification" in the singular. If it fails, the work still stands: report the work with its links, mention the failed notification in one line, and retry at most twice.

Input Schema

NameRequiredDescriptionDefault
urlYesA ready-to-use absolute https URL on xtiles.app that opens the result (you build this URL yourself — the backend does not resolve a destination from ids). If you added tiles anywhere — a project page or a planner day, new or existing — use the `resource_url` the creating tool returned for the FIRST added tile, so the app scrolls to it. Link a page (`parent_resource_url` / `link`) only when you created that page or project itself. Only tasks, no tiles: link the planner day they are due on — https://xtiles.app/<view_id>, with the view_id from reading that day. Never invent a path; never the home screen or the project list.
textYes1–2 facts from the result not already in the headline (count, time, person, date, topic), then a short call to action. With no concrete detail, write a fixed phrase and the call to action; never invent. Call to action always, facts or not. Max 100 chars. Language of the person or their content — the call to action in that language too. No assistant name, marketing or emoji pile. Examples show the shape only — write yours in that language. Examples: Daily Brief: "3 tasks due, sync at 11:00. Tap to see details", Budget approved: "40k for Q4, sign-off by Friday. Tap to open", no facts: "Your plan for today is ready. Tap to open".
titleNoRequired on every call, though the schema allows omitting it. What happened, in a few words. Max 60 chars, one line, no assistant name. In the person's language: translate "is ready", keep only the routine's name as given. Scheduled run or workflow: "<its name> is ready", identical every run (verbatim if its instructions give one). Examples show the shape only — write yours in that language. Examples: "Daily Brief is ready", "Weekly Review is ready", "Budget approved".
agent_sourceNoA raw label identifying the calling client, e.g. "Claude". Unrecognized values are accepted.

Output Schema

NameRequiredDescriptionDefault
sentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / text / description
      Previous value: -"The notification's full display text. Compose it yourself: who (the agent), what it did, and where, with a count if it summarizes several changes in one place. One short sentence — the app shows at most 100 characters and cuts off the rest, and longer text is rejected. Examples: \"Claude added 3 tasks to the \\\"Marketing\\\" project\", \"Claude updated \\\"Launch\\\" project: tile + 5 tasks\"."New value: +"1–2 facts from the result not already in the headline (count, time, person, date, topic), then a short call to action. With no concrete detail, write a fixed phrase and the call to action; never invent. Call to action always, facts or not. Max 100 chars. Language of the person or their content — the call to action in that language too. No assistant name, marketing or emoji pile. Examples show the shape only — write yours in that language. Examples: Daily Brief: \"3 tasks due, sync at 11:00. Tap to see details\", Budget approved: \"40k for Q4, sign-off by Friday. Tap to open\", no facts: \"Your plan for today is ready. Tap to open\"."
    • changedInput schema / properties / title / description
      Previous value: -"Optional short headline shown above `text` in the phone notification: what happened, in a few words. At most 60 characters, one line. Do not put the agent's name here (the app already shows which agent sent it). Examples: \"Daily Brief is ready\", \"Sprint plan updated\"."New value: +"Required on every call, though the schema allows omitting it. What happened, in a few words. Max 60 chars, one line, no assistant name. In the person's language: translate \"is ready\", keep only the routine's name as given. Scheduled run or workflow: \"<its name> is ready\", identical every run (verbatim if its instructions give one). Examples show the shape only — write yours in that language. Examples: \"Daily Brief is ready\", \"Weekly Review is ready\", \"Budget approved\"."
    • changedInput schema / properties / url / description
      Previous value: -"A ready-to-use absolute https URL on xtiles.app to the page where the work is visible (you build this URL yourself — the backend does not resolve a destination from ids). Must point at a page (e.g. the Daily planner for pure task creation, or the project/page you changed), not a specific tile. Example: https://xtiles.app/..."New value: +"A ready-to-use absolute https URL on xtiles.app that opens the result (you build this URL yourself — the backend does not resolve a destination from ids). If you added tiles anywhere — a project page or a planner day, new or existing — use the `resource_url` the creating tool returned for the FIRST added tile, so the app scrolls to it. Link a page (`parent_resource_url` / `link`) only when you created that page or project itself. Only tasks, no tiles: link the planner day they are due on — https://xtiles.app/<view_id>, with the view_id from reading that day. Never invent a path; never the home screen or the project list."
  2. Changed1 schema field changed
    • addedInput schema / properties / title
      Added value: +{
      +  "description": "Optional short headline shown above `text` in the phone notification: what happened, in a few words. At most 60 characters, one line. Do not put the agent's name here (the app already shows which agent sent it). Examples: \"Daily Brief is ready\", \"Sprint plan updated\".",
      +  "maxLength": 60,
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only flag it as a non-idempotent, open-world write; the description adds delivery mechanics (in-app feed + mobile push, no recipient), an ordering constraint (must be the very last calls of the turn, nothing after), batching semantics (one per changed place, never per task), and failure behavior (work stands, note the failure, retry at most twice). This is substantial context beyond the structured fields.

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 purpose, then clearly segmented into WHEN and HOW, so it is navigable. It is nonetheless dense and repetitive in places (restating the no-notification-after-a-live-request rule), leaving a little fat despite every section being relevant.

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?

Given four parameters, a 100% schema coverage, an output schema already present, and annotation coverage, the description fills the remaining gaps an agent needs: when it is appropriate, exact ordering, cardinality of calls, and recovery on failure. Nothing material is missing.

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% and the schema itself is unusually rich, so the baseline is 3. The description still adds value beyond the schema by making `title` mandatory on every call even though the schema does not require it, and by reinforcing the language/length constraints for text.

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 (create) and resource (notification) plus the exact scope: the owner of the account you're working in, about work they didn't watch happen. It also immediately clarifies there is no recipient parameter, which distinguishes it from anything resembling a messaging tool among the siblings.

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 numbered WHEN list (scheduled/recurring run, explicit request, agreed schedule setup) and an explicit exclusion (never after an ordinary one-off live request, and do not offer one there). No other sibling competes for this behavior, and the conditions are unambiguous.

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