Smart Calendars AI
io.github.jlohmeier/smart-calendars-aijlohmeierstreamable-httpv2.0.0Scanned
Create and update subscription calendars from ChatGPT, Claude, or Codex.
7 tools: 2 can delete or cancel things, 2 change things and 3 only read.
- Reads private data · 0
- Reads text others write · 4
- Can send data out · 0
- 6 findings
Anlyon alternative
4 of these tools change something. Run those as governed actions.
Declare what an action changes, and Anlyon puts it under a shared limit, binds every approval to the exact request, and grades the outcome. It works on any HTTPS API you can describe as an action.
Anlyon does not run, proxy or govern this MCP server. A tool your own code calls directly is not routed through Anlyon and is not governed by it.
Import an OpenAPI spec →Tools
Grouped by what each tool does, most consequential first. Open one for its reasons and full description; descriptions are the publisher's own words.
7 tools
Deletes or cancels 2Claude Code: deny
apply_feed_changesSave one revision to one existing calendar feed owned by the connected account.Reads text others write4 findings
Why it is in this group
- The name "apply_feed_changes" says "apply": a word for a change.
- The server marks it destructive (destructiveHint: true).
What it can reach
- untrusted-inputThe server marks it openWorldHint: true: it reaches things outside the server's own data.
Findings
- Info
The input schema at properties.operations.items.oneOf[0].properties.event.properties.description.description mentions "credentials".
What this check looks forMatched text
inputSchema.properties.operations.items.oneOf[0].properties.event.properties.description.description: "...this calendar. Never send chat history, credentials, health records or unrelated personal c..."
- Info
The input schema at properties.operations.items.oneOf[1].properties.set.properties.description.description mentions "credentials".
What this check looks forMatched text
inputSchema.properties.operations.items.oneOf[1].properties.set.properties.description.description: "...this calendar. Never send chat history, credentials, health records or unrelated personal c..."
- Info
The input schema at properties.operations.items.oneOf[3].properties.set.properties.description.description mentions "credentials".
What this check looks forMatched text
inputSchema.properties.operations.items.oneOf[3].properties.set.properties.description.description: "...this calendar. Never send chat history, credentials, health records or unrelated personal c..."
- Info
The description is 4,988 characters long, over the 2,000 this check looks for.
What this check looks forMatched text
description ends: "...calendar app. Do not present inactive or unpublished feeds as ready to subscribe."
Description, as the server wrote it Save one revision to one existing calendar feed owned by the connected account. Submit one fixed-schema change set with up to 250 event changes and/or a feed title or description change; all stored calendar changes commit together in one transaction, or none are saved. The input schema declares every supported change: add creates an event; update changes selected fields or uses reset_fields to restore saved field baselines; delete marks an existing event canceled without permanently erasing it; restore reinstates that same event and may update selected fields; feed_patch changes only the calendar title or description. No dynamic operation discovery, fetched schemas, arbitrary commands or arbitrary endpoints are supported. First use dry_run=true to validate and preview the change set without saving, advancing the revision or spending credits. Show the returned before/after changes and any billing quote, not an invented summary. Obtain approval for a proposed schedule revision before saving it with dry_run=false. Save with the returned preview_receipt and the identical feed_id, expected_revision, request_id, operations and feed_patch. The receipt binds that validated preview, not user consent. Changed proposals or expired previews require a new preview and approval; revision conflicts require reading the feed again before preparing a new preview. Preserve omitted events/fields. For revised PDFs/documents, read the complete unfiltered feed before cancellations, preserve unrelated events and manual fields, and ask when an event match is uncertain. Update matched event IDs; a duplicate add is not an update. Use set with null to clear nullable fields; reset_fields restores saved baselines, not empty values. Use the last read expected_revision to prevent overwriting concurrent changes. On uncertain save retry the identical request_id and payload, including the original preview_receipt, never a new one. Subscribers save without billing prompts. If billing requires one credit, show the deduction and balance and obtain explicit user authorization before setting confirm_credit_charge=true; this explicit authorization may be added after preview. Default automations must not authorize credit spending. publication.status reports calendar-file preparation, not subscription access. Check distribution_ready for access at the reported revision; use get_feed_status for current availability. Preview proposals are recoverable for up to one hour; expired drafts are removed automatically. Previewing does not write calendar events or advance their revision. Display the returned feed_id and request_id alongside the preview summary so this exact proposal can be recovered. If the receipt or exact proposal was lost, call this same tool with only feed_id, the original request_id, dry_run=true and recover_preview=true. Do not reconstruct missing changes from memory, guess a key or choose a latest preview. Recovery returns the original unexpired preview and exact save_arguments without extending its expiry, saving or spending credits. Show that recovered preview and obtain fresh approval before submitting its save_arguments unchanged; confirm_credit_charge remains false unless the user explicitly authorizes the current quoted charge. Recovery is not consent. If recovery returns saved=true, those changes were already saved: report that result and stop; do not submit a new save. If no recoverable preview remains, read the feed, prepare a new preview with a new request_id and obtain approval. Never silently substitute a changed proposal. These tools manage Smart Calendars feeds only; they cannot access mailboxes or start source monitoring, scheduled PDF checks or document refreshes. For requests solely for those unsupported actions, explain the limitation without reading feeds or substituting an edit. For unsupported mailbox requests, offer to work with schedule content the user chooses to provide instead. General ICS explanations need no account access. When sharing a feed or filtered_subscription with distribution_ready=true, offer "Open in calendar app" using that object’s HTTPS subscription_open_url (it redirects to webcal), and "Calendar options" using its subscription_options_url for Apple/default, Google, Outlook and copy-link choices. Retain subscription_url as a copyable HTTPS fallback. Prefer these HTTPS handoff links over putting subscription_webcal_url directly in chat, because some clients do not preserve clickable webcal links. If a handoff URL is absent, use the HTTPS subscription_url and dashboard subscription controls instead. Offer "View or edit" using the feed’s manage_url. For a filtered selection use the nested filtered_subscription links, not the unfiltered feed links. Use the returned URLs exactly; never invent or rewrite their host, path or token. Opening a link does not confirm a subscription; the user must confirm in their calendar app. Do not present inactive or unpublished feeds as ready to subscribe.
Annotations the server declares
- readOnlyHint: false
- destructiveHint: true
- idempotentHint: true
- openWorldHint: true
deactivate_feedDeactivate a feed without deleting events or resetting editing windows.Reads text others writeNo findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
- The server marks it destructive (destructiveHint: true).
What it can reach
- untrusted-inputThe server marks it openWorldHint: true: it reaches things outside the server's own data.
Description, as the server wrote it Deactivate a feed without deleting events or resetting editing windows. Confirm the user wants to interrupt subscription access. publication.status reports calendar-file preparation, not subscription access. Check distribution_ready for access at the reported revision; use get_feed_status for current availability. These tools manage Smart Calendars feeds only; they cannot access mailboxes or start source monitoring, scheduled PDF checks or document refreshes. For requests solely for those unsupported actions, explain the limitation without reading feeds or substituting an edit. For unsupported mailbox requests, offer to work with schedule content the user chooses to provide instead. General ICS explanations need no account access. When sharing a feed or filtered_subscription with distribution_ready=true, offer "Open in calendar app" using that object’s HTTPS subscription_open_url (it redirects to webcal), and "Calendar options" using its subscription_options_url for Apple/default, Google, Outlook and copy-link choices. Retain subscription_url as a copyable HTTPS fallback. Prefer these HTTPS handoff links over putting subscription_webcal_url directly in chat, because some clients do not preserve clickable webcal links. If a handoff URL is absent, use the HTTPS subscription_url and dashboard subscription controls instead. Offer "View or edit" using the feed’s manage_url. For a filtered selection use the nested filtered_subscription links, not the unfiltered feed links. Use the returned URLs exactly; never invent or rewrite their host, path or token. Opening a link does not confirm a subscription; the user must confirm in their calendar app. Do not present inactive or unpublished feeds as ready to subscribe.
Annotations the server declares
- readOnlyHint: false
- destructiveHint: true
- idempotentHint: true
- openWorldHint: true
Changes things 2Claude Code: ask
create_feedCreate and activate a subscription calendar from structured events.Reads text others write1 finding
Why it is in this group
- The name "create_feed" says "create": a word for a change.
What it can reach
- untrusted-inputThe server marks it openWorldHint: true: it reaches things outside the server's own data.
Findings
- Info
The input schema at properties.events.items.properties.event.properties.description.description mentions "credentials".
What this check looks forMatched text
inputSchema.properties.events.items.properties.event.properties.description.description: "...this calendar. Never send chat history, credentials, health records or unrelated personal c..."
Description, as the server wrote it Create and activate a subscription calendar from structured events. Extract the schedule yourself first. Free within feed allowances. No automatic monitoring is enrolled. Reuse request_id on retries. publication.status reports calendar-file preparation, not subscription access. Check distribution_ready for access at the reported revision; use get_feed_status for current availability. These tools manage Smart Calendars feeds only; they cannot access mailboxes or start source monitoring, scheduled PDF checks or document refreshes. For requests solely for those unsupported actions, explain the limitation without reading feeds or substituting an edit. For unsupported mailbox requests, offer to work with schedule content the user chooses to provide instead. General ICS explanations need no account access. When sharing a feed or filtered_subscription with distribution_ready=true, offer "Open in calendar app" using that object’s HTTPS subscription_open_url (it redirects to webcal), and "Calendar options" using its subscription_options_url for Apple/default, Google, Outlook and copy-link choices. Retain subscription_url as a copyable HTTPS fallback. Prefer these HTTPS handoff links over putting subscription_webcal_url directly in chat, because some clients do not preserve clickable webcal links. If a handoff URL is absent, use the HTTPS subscription_url and dashboard subscription controls instead. Offer "View or edit" using the feed’s manage_url. For a filtered selection use the nested filtered_subscription links, not the unfiltered feed links. Use the returned URLs exactly; never invent or rewrite their host, path or token. Opening a link does not confirm a subscription; the user must confirm in their calendar app. Do not present inactive or unpublished feeds as ready to subscribe.
Annotations the server declares
- readOnlyHint: false
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
reactivate_feedReactivate an existing feed free within account allowances.Reads text others writeNo findings
Why it is in this group
- Nothing in its name or description says what it does, so it is counted as a write.
What it can reach
- untrusted-inputThe server marks it openWorldHint: true: it reaches things outside the server's own data.
Description, as the server wrote it Reactivate an existing feed free within account allowances. Does not reset the original editing window or modify events. publication.status reports calendar-file preparation, not subscription access. Check distribution_ready for access at the reported revision; use get_feed_status for current availability. These tools manage Smart Calendars feeds only; they cannot access mailboxes or start source monitoring, scheduled PDF checks or document refreshes. For requests solely for those unsupported actions, explain the limitation without reading feeds or substituting an edit. For unsupported mailbox requests, offer to work with schedule content the user chooses to provide instead. General ICS explanations need no account access. When sharing a feed or filtered_subscription with distribution_ready=true, offer "Open in calendar app" using that object’s HTTPS subscription_open_url (it redirects to webcal), and "Calendar options" using its subscription_options_url for Apple/default, Google, Outlook and copy-link choices. Retain subscription_url as a copyable HTTPS fallback. Prefer these HTTPS handoff links over putting subscription_webcal_url directly in chat, because some clients do not preserve clickable webcal links. If a handoff URL is absent, use the HTTPS subscription_url and dashboard subscription controls instead. Offer "View or edit" using the feed’s manage_url. For a filtered selection use the nested filtered_subscription links, not the unfiltered feed links. Use the returned URLs exactly; never invent or rewrite their host, path or token. Opening a link does not confirm a subscription; the user must confirm in their calendar app. Do not present inactive or unpublished feeds as ready to subscribe.
Annotations the server declares
- readOnlyHint: false
- destructiveHint: false
- idempotentHint: true
- openWorldHint: true
Only reads 3Show 3 read-only tools
get_feedRead events and the internal revision before editing.1 finding
Why it is in this group
- The name "get_feed" says "get": a word for reading.
Findings
- Info
The description is 2,336 characters long, over the 2,000 this check looks for.
What this check looks forMatched text
description ends: "...anyone with the link can remove the filters and read the full published calendar."
Description, as the server wrote it Read events and the internal revision before editing. Request include_facets first and select returned values for known labels. Facet results describe the entire published active feed, independent of read filters or pagination. Nonempty filters also return filtered_subscription with canonical filters, matching_event_count and unmatched_filter_values. Use its URLs for that selection; top-level subscription URLs remain unfiltered. Event IDs, external keys, dates, removal state and pagination narrow only the read, never the subscription. Filtering changes no events and creates no cloned feed. Before proposing cancellations from a revised PDF/document, read every page of the unfiltered feed; never infer deletion from omitted events. These tools manage Smart Calendars feeds only; they cannot access mailboxes or start source monitoring, scheduled PDF checks or document refreshes. For requests solely for those unsupported actions, explain the limitation without reading feeds or substituting an edit. For unsupported mailbox requests, offer to work with schedule content the user chooses to provide instead. General ICS explanations need no account access. When sharing a feed or filtered_subscription with distribution_ready=true, offer "Open in calendar app" using that object’s HTTPS subscription_open_url (it redirects to webcal), and "Calendar options" using its subscription_options_url for Apple/default, Google, Outlook and copy-link choices. Retain subscription_url as a copyable HTTPS fallback. Prefer these HTTPS handoff links over putting subscription_webcal_url directly in chat, because some clients do not preserve clickable webcal links. If a handoff URL is absent, use the HTTPS subscription_url and dashboard subscription controls instead. Offer "View or edit" using the feed’s manage_url. For a filtered selection use the nested filtered_subscription links, not the unfiltered feed links. Use the returned URLs exactly; never invent or rewrite their host, path or token. Opening a link does not confirm a subscription; the user must confirm in their calendar app. Do not present inactive or unpublished feeds as ready to subscribe. When returning a filtered subscription, explain: filters select events, not who can access them; anyone with the link can remove the filters and read the full published calendar.
Annotations the server declares
- readOnlyHint: true
- destructiveHint: false
- idempotentHint: true
- openWorldHint: false
get_feed_statusRead the feed’s last update, subscription availability (distribution_ready), editing access and configured monitoring status.No findings
Why it is in this group
- The name "get_feed_status" says "get": a word for reading.
Description, as the server wrote it Read the feed’s last update, subscription availability (distribution_ready), editing access and configured monitoring status. This does not refresh or charge. These tools manage Smart Calendars feeds only; they cannot access mailboxes or start source monitoring, scheduled PDF checks or document refreshes. For requests solely for those unsupported actions, explain the limitation without reading feeds or substituting an edit. For unsupported mailbox requests, offer to work with schedule content the user chooses to provide instead. General ICS explanations need no account access. When sharing a feed or filtered_subscription with distribution_ready=true, offer "Open in calendar app" using that object’s HTTPS subscription_open_url (it redirects to webcal), and "Calendar options" using its subscription_options_url for Apple/default, Google, Outlook and copy-link choices. Retain subscription_url as a copyable HTTPS fallback. Prefer these HTTPS handoff links over putting subscription_webcal_url directly in chat, because some clients do not preserve clickable webcal links. If a handoff URL is absent, use the HTTPS subscription_url and dashboard subscription controls instead. Offer "View or edit" using the feed’s manage_url. For a filtered selection use the nested filtered_subscription links, not the unfiltered feed links. Use the returned URLs exactly; never invent or rewrite their host, path or token. Opening a link does not confirm a subscription; the user must confirm in their calendar app. Do not present inactive or unpublished feeds as ready to subscribe.
Annotations the server declares
- readOnlyHint: true
- destructiveHint: false
- idempotentHint: true
- openWorldHint: false
list_feedsList the connected account’s feeds, management links and shared active-feed allowance.No findings
Why it is in this group
- The name "list_feeds" says "list": a word for reading.
Description, as the server wrote it List the connected account’s feeds, management links and shared active-feed allowance. Only feeds marked counts_towards_active_limit use a slot; this page’s length is not the account’s usage. Deactivating a counted feed frees a slot but interrupts its subscription access, so ask the user first. These tools manage Smart Calendars feeds only; they cannot access mailboxes or start source monitoring, scheduled PDF checks or document refreshes. For requests solely for those unsupported actions, explain the limitation without reading feeds or substituting an edit. For unsupported mailbox requests, offer to work with schedule content the user chooses to provide instead. General ICS explanations need no account access. When sharing a feed or filtered_subscription with distribution_ready=true, offer "Open in calendar app" using that object’s HTTPS subscription_open_url (it redirects to webcal), and "Calendar options" using its subscription_options_url for Apple/default, Google, Outlook and copy-link choices. Retain subscription_url as a copyable HTTPS fallback. Prefer these HTTPS handoff links over putting subscription_webcal_url directly in chat, because some clients do not preserve clickable webcal links. If a handoff URL is absent, use the HTTPS subscription_url and dashboard subscription controls instead. Offer "View or edit" using the feed’s manage_url. For a filtered selection use the nested filtered_subscription links, not the unfiltered feed links. Use the returned URLs exactly; never invent or rewrite their host, path or token. Opening a link does not confirm a subscription; the user must confirm in their calendar app. Do not present inactive or unpublished feeds as ready to subscribe.
Annotations the server declares
- readOnlyHint: true
- destructiveHint: false
- idempotentHint: true
- openWorldHint: false
This is not a safety rating, and no finding is not a safety guarantee. The groups and findings come from fixed checks of the tool definitions the server returned on the date shown, not from its code or what it does when called. How the checks work.
Exfil surface
Which tools read private data, which read text someone else can write, and which can send data out. One of each is a path a prompt injection can use.
No private-data, untrusted-input, outbound path in this server alone: no tool is tagged private-data or outbound.
- Reads private data0
- Reads files, mail, messages, databases, secrets, calendars or repositories.
- Reads text others write4
- Brings in text someone else can write: web pages, inbound email, messages, issues and comments.
- Can send data out0
- Can carry data to people or systems: it sends, posts or publishes, or takes a recipient, channel or URL.
Other servers in the same agent add their own tools to these paths. Audit your whole setup to see them together.
Findings
Matches of fixed checks, with the text they matched.
- Infocreate_feed
The input schema at properties.events.items.properties.event.properties.description.description mentions "credentials".
What this check looks forMatched text
inputSchema.properties.events.items.properties.event.properties.description.description: "...this calendar. Never send chat history, credentials, health records or unrelated personal c..."
- Infoget_feed
The description is 2,336 characters long, over the 2,000 this check looks for.
What this check looks forMatched text
description ends: "...anyone with the link can remove the filters and read the full published calendar."
The input schema at properties.operations.items.oneOf[0].properties.event.properties.description.description mentions "credentials".
What this check looks forMatched text
inputSchema.properties.operations.items.oneOf[0].properties.event.properties.description.description: "...this calendar. Never send chat history, credentials, health records or unrelated personal c..."
The input schema at properties.operations.items.oneOf[1].properties.set.properties.description.description mentions "credentials".
What this check looks forMatched text
inputSchema.properties.operations.items.oneOf[1].properties.set.properties.description.description: "...this calendar. Never send chat history, credentials, health records or unrelated personal c..."
The input schema at properties.operations.items.oneOf[3].properties.set.properties.description.description mentions "credentials".
What this check looks forMatched text
inputSchema.properties.operations.items.oneOf[3].properties.set.properties.description.description: "...this calendar. Never send chat history, credentials, health records or unrelated personal c..."
The description is 4,988 characters long, over the 2,000 this check looks for.
What this check looks forMatched text
description ends: "...calendar app. Do not present inactive or unpublished feeds as ready to subscribe."
History
Changes to its tool definitions and to its remote endpoint, newest first.
No change seen yet. Its tools are rescanned every day, and a remote endpoint is looked at once a week.
Install
Pinned to version 2.0.0. Values in angle brackets are yours to fill in.
claude mcp add --transport http smart-calendars-ai https://api.smartcalendars.ai/mcpclaude mcp add --transport http smart-calendars-ai https://api.smartcalendars.ai/mcpRun in a terminal.
Claude Code permissions
Allow the reads, ask before a change or a way out, deny the deletes. Paste into .claude/settings.json.
{
"permissions": {
"allow": [
"mcp__smart-calendars-ai__list_feeds",
"mcp__smart-calendars-ai__get_feed",
"mcp__smart-calendars-ai__get_feed_status"
],
"ask": [
"mcp__smart-calendars-ai__create_feed",
"mcp__smart-calendars-ai__reactivate_feed"
],
"deny": [
"mcp__smart-calendars-ai__apply_feed_changes",
"mcp__smart-calendars-ai__deactivate_feed"
]
}
}Tools that only read are allowed, tools that change things ask first, tools that delete or cancel are denied. A read that can send data out (it takes a URL, say) asks first too. It assumes the server is installed as smart-calendars-ai. Review it before you use it.
Capability tags behind 4 rules
- mcp__smart-calendars-ai__create_feed untrusted-input
- mcp__smart-calendars-ai__apply_feed_changes untrusted-input
- mcp__smart-calendars-ai__deactivate_feed untrusted-input
- mcp__smart-calendars-ai__reactivate_feed untrusted-input
Pin
Keep the decision: fail CI when the tools change, follow every change, or show a badge.
Pin in CI
Fail a build when the tools you reviewed are not the tools the server serves today.
curl -s "https://anlyon.dev/api/v1/servers/io.github.jlohmeier/smart-calendars-ai/verify?hash=b3c5f9c35d8cf1314fc0c6611df5f5ad91464e4922cec4087f66aa28fff401e2" | jq -e '.changed == false'Pinned hash b3c5f9c35d8c, from Oct 23, 2026, 10:18 UTC.
Watch
Get told when its tools change: a new tool, a new description, a new class.
https://anlyon.dev/servers/io.github.jlohmeier/smart-calendars-ai/changes.xmlAn Atom feed. Works in any feed reader or Slack's RSS app.
Badge
[](https://anlyon.dev/servers/io.github.jlohmeier/smart-calendars-ai)Source: MCP Registry. Synced Oct 23, 2026, 10:18 UTC.