The setup #
I’m an Apple person. Notes for thinking, Reminders for doing. It’s simple, it syncs everywhere, and it stays out of my way. I’ve used Reminders for years to track what needs to happen and when.
But as I started spending more time in AI-powered development environments like Kiro, I noticed a friction point: every time I thought of a task while coding, I had to switch apps to add it to Reminders. Context switch, lose focus, come back, try to remember where I was. The classic productivity killer.
What if I could just tell Kiro “remind me to follow up with the customer on Thursday” and have it show up in Apple Reminders?
Attempt 1: An MCP server #
My first approach was building an MCP (Model Context Protocol) server. MCP is a standard that lets AI tools connect to external systems — databases, APIs, local tools — through a structured interface. It’s powerful and well-supported in Kiro.
The MCP server worked great. I could create reminders, list them, mark them complete, all from within Kiro. The integration was solid.
But there was a catch.
The context window problem #
MCP servers are always loaded. When Kiro starts a session, it loads the tool definitions for every configured MCP server into the context window. That means even in a session where I’m purely writing code and don’t need Reminders at all, the MCP server’s tool schemas are sitting there taking up space.
For a single MCP server, that’s not a big deal. But if you’re like me and have several MCP servers configured, the context window overhead adds up. Every token spent on tool definitions is a token not available for your actual work.
I wanted Reminders integration to be available when I need it, not consuming resources when I don’t.
Attempt 2: A Kiro skill #
Kiro has a concept called skills — markdown files that contain instructions, context, and tool definitions that are only loaded when activated. Think of it as on-demand capability instead of always-on.
The key insight: Apple Reminders is scriptable via AppleScript, and Kiro can execute shell commands. So instead of a full MCP server with a runtime process, I could write a skill that teaches Kiro how to use osascript to interact with Reminders directly.
Here is an outline of the SKILL.md
---
name: apple-reminders
description: Manage Apple Reminders using osascript. Use when the user asks about tasks, reminders, to-dos, or personal task management.
---
# Apple Reminders
## Available Lists
Get all list names:
\```bash
osascript -e 'tell application "Reminders" to get name of every list'
\```
## Add a Reminder
Create a reminder. Only `name` is required. `body` and `due date` are optional.
Without due date:
\```bash
osascript -e '
tell application "Reminders"
tell list "LIST_NAME"
make new reminder with properties {name:"TITLE", body:"NOTES"}
end tell
end tell'
\```
## Error Handling
- If a list is not found, AppleScript returns error -1728. Tell the user the list doesn't exist and show available lists.
- If a reminder is not found, tell the user and list current reminders in that list.
- Name matching is exact. If the user gives a partial name, list reminders first and confirm which one.The skill file contains:
- Instructions on how to interact with Apple Reminders
- AppleScript commands for creating, listing, completing, and deleting reminders
- Context about how Reminders organizes data (lists, due dates, priorities)
When I need it, I activate the skill. When I don’t, it’s just a markdown file on disk — zero context window impact.
The comparison #
| MCP Server | Kiro Skill | |
|---|---|---|
| Always loaded | Yes — tool schemas in every session | No — activated on demand |
| Context window cost | Constant overhead | Zero when not in use |
| Response speed | Fast | Fast (AppleScript is near-instant) |
| Setup complexity | Node.js/Python runtime, config in mcp.json | Single markdown file |
| Maintenance | Dependencies, versioning, process management | Edit a text file |
| Capability | Full programmatic access | Same — AppleScript covers all the operations |
For a tool I use in maybe 1 out of 5 sessions, the skill approach is clearly better. The MCP server would make more sense for something I need in every session, like a database connection or a deployment tool.
When to use which #
Use an MCP server when:
- You need the tool in most or all sessions
- The integration requires complex state management or long-running connections
- You’re connecting to external APIs that need authentication flows
- Multiple people on your team need the same integration
Use a Kiro skill when:
- You need the tool occasionally, not every session
- The underlying system is scriptable via CLI or shell commands
- You want zero overhead when the tool isn’t active
- The integration is personal (your machine, your apps, your workflow)
The result #
The skill works exactly as well as the MCP server did, but with none of the overhead. I can say “add a reminder to follow up with the customer next Thursday” and it shows up in Apple Reminders within a second. When I’m in a pure coding session, the skill sits dormant and my full context window is available for code.
Sometimes the simpler approach is the better one. Not every integration needs a server.