show_dayRender the user's day as the interactive 24-hour reassign dial, right in the conversation — use it whenever they want to SEE their day, their schedule laid out, how full it looks, or to visually move things around. Defaults to today; pass date (ISO YYYY-MM-DD) for another day. For reading or reasoning about the plan in text, prefer get_schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
Changes observed during successful MCP inspections.
Input schema / additionalPropertiesAdded value: +falseInput schema / properties / llm_modelRemoved value: -{
- "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
- "type": "string"
-}Input schema / requiredRemoved value: -[
- "llm_model"
-]Input schema / properties / conversation_idRemoved value: -{
- "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
- "type": "string"
-}Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / conversation_idAdded value: +{
+ "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+ "type": "string"
+}Input schema / properties / llm_modelAdded value: +{
+ "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "llm_model"
+]Input schema / additionalPropertiesAdded value: +falseInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: the output is an interactive dial embedded in the conversation, the date defaults to today, and read-only textual reasoning belongs in get_schedule. It does not clarify whether the 'move things around' affordance mutates state (which would be worth stating against readOnlyHint), leaving a small gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tightly packed paragraph with zero filler: purpose front-loaded, then usage triggers, then default/format for the single parameter, then the routing alternative. Every clause earns its place and the ordering matches how an agent scans for a decision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does describe what the agent gets back (an interactive dial rendered in the conversation) and covers the only parameter's default and format. What remains thin is the interactive surface itself — what the user can do inside the rendered dial and whether those actions change data — which matters given readOnlyHint=true.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter and schema description coverage is 0%, so the description must carry the meaning — and it does, stating the default ('Defaults to today') and the accepted format ('ISO YYYY-MM-DD'), which the schema only encodes as a regex pattern. It does not describe behavior for invalid or out-of-range dates, so it is not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Render the user's day as the interactive 24-hour reassign dial') and immediately scopes it as an in-conversation visual. It distinguishes itself from the closest sibling by explicitly naming get_schedule as the text alternative, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger set ('whenever they want to SEE their day, their schedule laid out, how full it looks, or to visually move things around') and an explicit counter-condition ('For reading or reasoning about the plan in text, prefer get_schedule'). Both the when and the when-not are present with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.