xTiles

xtiles_create_tiles_from_markdown_in_project_planner

Destructive

Append tiles generated from Markdown into a project planner for the period containing the given date. Returns the affected view_id, tiles (each created tile's id and resource_url — a deep link that opens the page focused on that tile), and parent_resource_url (a link that opens the page the tiles were created on). New tiles arrive at one default size, in import order — arrange them next (xtiles_get_page_layout, then xtiles_set_page_layout for the ids returned here); how, and whether the page already passes, is in xtiles://guide/markdown/design.

Input Schema

Name	Required	Description
`date`	Yes	Anchor date (ISO 8601, e.g. "2026-04-24"). Tiles are created in the planner range containing this date.
`period`	Yes	Planner period: e.g. "day", "week", "month".
`markdown`	Yes	Markdown content to convert into tiles. Each top-level heading (`### Title`) typically becomes a separate tile; paragraphs, lists, and code blocks under a heading become its body. Tiles are appended to existing content (not replaced). They all go into one existing page: no `##` page headings — a second `##` is refused. Full syntax: read resource `xtiles://guide/markdown/overview` or call `xtiles_get_docs`. The target already exists, so continue its palette: read its tile colours (`xtiles_get_tile_styles`) before writing, and write the same colours inline (`@color` / `@colorSize`). Rules: `xtiles://guide/markdown/design`.
`projectId`	Yes	Project ID whose planner is the target.

Output Schema

Name	Required	Description	Default
`tiles`	No
`view_id`	No
`tile_ids`	No
`parent_resource_url`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

changedInput schema / properties / markdown / description

Previous value: -"Markdown content to convert into tiles. Each top-level heading (`### Title`) typically becomes a separate tile; paragraphs, lists, and code blocks under a heading become its body. Tiles are appended to existing content (not replaced). Full syntax: read resource `xtiles://guide/markdown/overview` or call `xtiles_get_docs`. The target already exists, so continue its palette: read its tile colours (`xtiles_get_tile_styles`) before writing, and write the same colours inline (`@color` / `@colorSize`). Rules: `xtiles://guide/markdown/design`."New value: +"Markdown content to convert into tiles. Each top-level heading (`### Title`) typically becomes a separate tile; paragraphs, lists, and code blocks under a heading become its body. Tiles are appended to existing content (not replaced). They all go into one existing page: no `##` page headings — a second `##` is refused. Full syntax: read resource `xtiles://guide/markdown/overview` or call `xtiles_get_docs`. The target already exists, so continue its palette: read its tile colours (`xtiles_get_tile_styles`) before writing, and write the same colours inline (`@color` / `@colorSize`). Rules: `xtiles://guide/markdown/design`."

Changed1 schema field changedOct 8, 2026

changedInput schema / properties / markdown / description

Previous value: -"Markdown content to convert into tiles. Each top-level heading (`### Title`) typically becomes a separate tile; paragraphs, lists, and code blocks under a heading become its body. Tiles are appended to existing content (not replaced). Full syntax: read resource `xtiles://guide/markdown/overview` or call `xtiles_get_docs`."New value: +"Markdown content to convert into tiles. Each top-level heading (`### Title`) typically becomes a separate tile; paragraphs, lists, and code blocks under a heading become its body. Tiles are appended to existing content (not replaced). Full syntax: read resource `xtiles://guide/markdown/overview` or call `xtiles_get_docs`. The target already exists, so continue its palette: read its tile colours (`xtiles_get_tile_styles`) before writing, and write the same colours inline (`@color` / `@colorSize`). Rules: `xtiles://guide/markdown/design`."

First observedOct 6, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already establish write/destructive/openWorld/non-idempotent semantics, and the description usefully adds that content is appended rather than replaced, that tiles arrive at a single default size in import order, and what the return envelope contains. It could say more about what 'destructive' means here (how existing layout is affected) given destructiveHint=true, but the append semantics are a real addition.

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?

Purpose is front-loaded in the first sentence, followed by return shape and then next-step guidance; every sentence is load-bearing. Minor overlap with schema content (append-not-replace) keeps it from a 5.

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 4-required-param write tool with an output schema and full annotation coverage, the description supplies the workflow chain, required pre-reads, and design-rule references an agent needs. Describing return values is partly redundant with the output schema, but nothing important is missing.

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%, so every parameter is already documented, and the description merely restates date ('period containing the given date') and markdown conversion at a high level. It adds no format, constraint, or edge-case detail beyond the schema, so the baseline 3 applies.

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+resource+target: 'Append tiles generated from Markdown into a project planner for the period containing the given date.' The phrase 'project planner' cleanly separates it from the sibling variants in_my_planner and by_view, so an agent can route without opening the schema.

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?

Gives clear forward context — tiles arrive at one default size in import order, so arrange them next via xtiles_get_page_layout then xtiles_set_page_layout using the returned ids — plus prerequisites (read tile colours before writing) and pointers to the design rules. It does not explicitly compare against the in_my_planner or by_view siblings, which is the only missing guidance.

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

All xTiles tools Inspect

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

Need Help?