Skip to content

TileSet changelog

com.tileset/tileset

2 changes recorded. MCP Harbor re-reads this listing from the official registry every six hours and asks the live server what it exposes, and keeps what changed between one look and the next.

  • llms.txt +21 −16

    https://tileset.com/llms.txt

    − > TileSet puts live social feeds and review widgets on any website. Connect a source (Google reviews, YouTube, Twitch, Kick live status, Bluesky, Mastodon, X, Pinterest Pins or testimonials the customer collects themselves), create a widget from it, then paste one script tag and one div into the site's HTML to render it.− - Tokens, limits and quotas: a platform's rate-limit answer keeps the last update and retries at the next refresh; Pinterest refreshes ask the upstream "changed since?" (If-None-Match, If-Modified-Since); the platform API keys and their quotas are TileSet's, not the site's.− - Light on the host page: one script, under 10 KB compressed (a budget the build enforces), with the lightbox and richer layouts loaded only when a widget uses them; no cookies, no framework or loader. Each widget mounts only as it nears the viewport, below-the-fold images load lazily, and tiles keep their aspect ratio while images arrive. Reserving the div's height (the embed guide's sizing section) removes the remaining layout shift.− 2. Ask: "Add my Google reviews to my homepage with TileSet". The agent calls setup_widget { "source": "google", "query": "<a Maps link or the business name>" }. Other sources work the same way, with "source" set to "youtube" (query: an @handle), "twitch" (query: a Twitch channel name or twitch.tv link), "kick" (query: a Kick channel name or kick.com link), "bluesky" (query: a Bluesky handle), "mastodon" (query: @name@server), "x" (query: an X @handle or x.com link), "pinterest" (query: a Pintere− - POST https://app.tileset.com/v1/sources {type, mode: "live", label? (omit it: the source is named after its account), query?, placeId?, channelHandle?, handle?, account?, pinterestUrl?, xHandle?, twitchChannel?, kickChannel?, updateEvery?} (connect_source's arguments plus mode) -> the source. Send mode "live": without it the source is a demo fixture with sample content, never fetched from the platform (connect_source always sends it), and a later live connect of the same address makes a new li− - POST https://app.tileset.com/v1/widgets {sourceId or sourceIds, type, title?, ...options} -> the widget; an account holds at most 200 widgets, and one more answers 409 {error, limit, hint} (create_widget and setup_widget the same). One widget embeds on any number of pages. sourceIds (1-4 ids) makes a mixed feed; more than one answers 403 {"error":"paid feature","feature":"mixed","availableIn":"Starter","reason"} below that tier, and a mixed widget carries sourceIds (sourceId is its first) and − Source types, by category. Social feeds: x: a public X account's posts from an xHandle (an @handle, or a link to its x.com or twitter.com profile). capability-dependent per environment (needs its X data service configured for a live source; trust GET /v1/me's sources.x flag or connect_source's own teaching error, not this text, to know whether it is enabled here). read through the X data service on this deployment, no sign-in: public accounts only, so a protected account is a teaching error at c− create_widget widget options: sourceId, string, required, id returned by list_sources or connect_source; with sourceIds, may be left out. sourceIds, array, 1-4, PAID, a mixed feed: 1-4 distinct source ids of any types the widget type can carry, the first one the widget's sourceId; on update it replaces the list (one id makes it single-source again), while a lone sourceId replaces only the first. More than one needs Starter or above. Items keep their own kind (a review card, a post card, a photo − Paid features: sourceIds: 2 or more ids (a mixed feed) needs Starter or above. A tenant below that tier gets HTTP 403 {"error":"paid feature","feature":"mixed","availableIn":"Starter","reason":"Included with Starter and up."}. Do not retry with the same value; it will not succeed on the tenant's current plan. minRating: 1-5 needs Growth or above. A tenant below that tier gets HTTP 403 {"error":"paid feature","feature":"minRating","availableIn":"Growth","reason":"Included with Growth and up."}. D− Link in bio: A Link in bio page lives at /@<slug> on the app's host; always give the customer the url the tools return, as returned (free pages are assigned a short address and cannot choose one; from Starter a slug of 3-30 lowercase letters, digits or hyphens can be chosen and changed, reserved words, our own routes and brand names are refused, and so is a slug someone else holds; a custom address chosen on a paid plan stays with the page if the subscription ends, while the page is viewed or ed−   kick, mastodon and pinterest: 1h 720, 3h 240, 6h 120, 12h 60, 1d 30, 3d 10, 1w 4−   On Starter and up: update_source_now (POST /v1/sources/:id/update) updates a source at once and spends what a scheduled update costs; manualOnly true stops its scheduled updates entirely; create_source_webhook gives a secret URL that updates it when called with POST, for a CMS publish hook, Zapier or a cron service. Each source has a cooldown of 5 minutes between manual and webhook updates, the same on every plan and a guard against accidental repeats rather than a cost control (longer for som−   The floor under every speed and every balance: EVERY source not paused for inactivity (below) is refreshed free of charge at least once per window, so no widget ever goes empty: 5 days for youtube sources, whose images are served from stored copies that expire, and 22 days for google, bluesky, mastodon, pinterest, x, twitch and kick sources, whose stored content expires on a longer clock. No step is offered that is slower than its type's window, since it would cost nothing. A twitch source is −   The whole platform fetches about 5 new Google places a day for free accounts, at most 2 for one account. Past either, a new Google source still connects and its first fetch waits until after 00:00 UTC: the answer carries queued (REST) or a Waiting line (MCP), list_sources says waiting, and nothing is charged until it is fetched. Paid accounts are never held. Why: The first gather of a new place's reviews is the expensive part, so the number of new Google places fetched each day is shared by ev−   Address checks: a live connect of Mastodon account reads that address from our network, so an account makes at most 120 of them an hour, failed ones included; past it the answer is 429 with reason addresses and nothing is fetched. Scheduled updates do not count.−   Connecting a source is one of two moments the balance can REFUSE something (the other is update_source_now or a webhook, above): a live source whose first refresh the balance cannot cover, after holding back the first refresh of every source not fetched yet, is not created, on any plan, and the answer is a 402 naming the credits it needs, the date the next allowance lands (when it is known) and what adds more. Every other call works at any balance. The month's cap never refuses a connect: a so+ > TileSet puts live social feeds and review widgets on any website. Connect a source (Google reviews, YouTube, Twitch, Kick live status, Kiyoh and Klantenvertellen reviews, an RSS or Atom feed, Bluesky, Mastodon, X, a calendar's upcoming events, Pinterest Pins or testimonials the customer collects themselves), create a widget from it, then paste one script tag and one div into the site's HTML to render it.+ - Tokens, limits and quotas: a platform's rate-limit answer keeps the last update and retries at the next refresh; RSS and Atom feeds and Pinterest refreshes ask the upstream "changed since?" (If-None-Match, If-Modified-Since); the platform API keys and their quotas are TileSet's, not the site's.+ - Light on the host page: one script, at most 13 KB compressed (a budget the build enforces), with the lightbox and richer layouts loaded only when a widget uses them; no cookies, no framework or loader. Each widget mounts only as it nears the viewport, below-the-fold images load lazily, and tiles keep their aspect ratio while images arrive. Reserving the div's height (the embed guide's sizing section) removes the remaining layout shift.+ 2. Ask: "Add my Google reviews to my homepage with TileSet". The agent calls setup_widget { "source": "google", "query": "<a Maps link or the business name>" }. Other sources work the same way, with "source" set to "youtube" (query: an @handle), "twitch" (query: a Twitch channel name or twitch.tv link), "kick" (query: a Kick channel name or kick.com link), "rss" (query: a feed or site address; a podcast connects as rss with "podcast": its name or Apple Podcasts link), "bluesky" (query: a Bluesky+ - POST https://app.tileset.com/v1/sources {type, mode: "live", label? (omit it: the source is named after its account), query?, placeId?, channelHandle?, feedUrl?, podcast?, handle?, account?, calendarUrl?, pinterestUrl?, xHandle?, twitchChannel?, kickChannel?, updateEvery?} (connect_source's arguments plus mode) -> the source; kiyoh connects from a dashboard session only (locationId, platform, apiToken) and an API key gets 403 with the dashboard link. Send mode "live": without it the source is + - POST https://app.tileset.com/v1/widgets {sourceId or sourceIds, type, title?, ...options} -> the widget (options as create_widget takes them, look included: "polished" unless sent, "plain" for a site with its own design; PATCH /v1/widgets/:id with only the fields to change updates them); an account holds at most 200 widgets, and one more answers 409 {error, limit, hint} (create_widget and setup_widget the same). One widget embeds on any number of pages. sourceIds (1-4 ids) makes a mixed feed; + Source types, by category. Social feeds: x: a public X account's posts from an xHandle (an @handle, or a link to its x.com or twitter.com profile). capability-dependent per environment (needs its X data service configured for a live source; trust GET /v1/me's sources.x flag or connect_source's own teaching error, not this text, to know whether it is enabled here). read through the X data service on this deployment, no sign-in: public accounts only, so a protected account is a teaching error at c+ create_widget widget options: sourceId, string, required, id returned by list_sources or connect_source; with sourceIds, may be left out. sourceIds, array, 1-4, PAID, a mixed feed: 1-4 distinct source ids of any types the widget type can carry, the first one the widget's sourceId; on update it replaces the list (one id makes it single-source again), while a lone sourceId replaces only the first. More than one needs Starter or above. Items keep their own kind (a review card, a post card, a photo + Paid features: sourceIds: 2 or more ids (a mixed feed) needs Starter or above. A tenant below that tier gets HTTP 403 {"error":"paid feature","feature":"mixed","availableIn":"Starter","reason":"Included with Starter and up."}. Do not retry with the same value; it will not succeed on the tenant's current plan. minRating: 1-5 needs Growth or above. A tenant below that tier gets HTTP 403 {"error":"paid feature","feature":"minRating","availableIn":"Growth","reason":"Included with Growth and up."}. D+ Link in bio: A Link in bio page lives at /@<slug> on the app's host; always give the customer the url the tools return, as returned (free pages are assigned a short address and cannot choose one; from Starter a slug of 3-30 lowercase letters, digits or hyphens can be chosen and changed, reserved words, our own routes and brand names are refused, and so is a slug someone else holds; a custom address chosen on a paid plan stays with the page if the subscription ends, while the page is viewed or ed+   ical: 1+   kiyoh: 1+   rss: 1+   kiyoh: 1d 30, 3d 10, 1w 4+   ical, kick, mastodon, pinterest and rss: 1h 720, 3h 240, 6h 120, 12h 60, 1d 30, 3d 10, 1w 4+   On Starter and up: update_source_now (POST /v1/sources/:id/update) updates a source at once and spends what a scheduled update costs; manualOnly true stops its scheduled updates entirely; create_source_webhook gives a secret URL that updates it when called with POST, for a CMS publish hook, Zapier or a cron service. Each source has a cooldown of 5 minutes between manual and webhook updates, the same on every plan and a guard against accidental repeats rather than a cost control (longer for som+   The floor under every speed and every balance: EVERY source not paused for inactivity (below) is refreshed free of charge at least once per window, so no widget ever goes empty: 5 days for youtube sources, whose images are served from stored copies that expire, and 22 days for google, rss, bluesky, mastodon, ical, pinterest, x, twitch, kick and kiyoh sources, whose stored content expires on a longer clock. No step is offered that is slower than its type's window, since it would cost nothing. A+   New Google places a month: a Free account starts the first fetch of at most 10 new Google places a calendar month (UTC). Past it, a new Google source still connects and its first fetch waits until 00:00 UTC on the 1st: the answer carries queued (REST) or a Waiting line (MCP), list_sources says waiting, and nothing is charged until it is fetched. Paid accounts are never held. Why: The first gather of a new place's reviews is the expensive part, so a free account starts at most 10 new Google pla+   Address checks: a live connect of a feed, podcast, Mastodon account or calendar reads that address from our network, so an account makes at most 120 of them an hour, failed ones included; past it the answer is 429 with reason addresses and nothing is fetched. Scheduled updates do not count.+   Connecting a source is one of two moments the balance can REFUSE something (the other is update_source_now or a webhook, above): a live source whose first refresh the balance cannot cover, after holding back the first refresh of every source not fetched yet, is not created, on any plan, and the answer is a 402 naming the credits it needs, the date the next allowance lands (when it is known) and what adds more. Every other call works at any balance. The month's cap never refuses a connect: a so+ Every widget renders in the polished look by default: a finished design with no CSS needed. When the site has its own design system and the widget should blend in, set look "plain" (update_widget, or PATCH /v1/widgets/:id: the host page's font, no shadows or hover effects) and set the --sbe- tokens to the site's values. Deeper restyling works in either look through the .sbe- class names. Both looks use the same markup and options.

  • server.json 2 fields changed
    repository_url
    — https://github.com/awesomemotive/tileset-mcp
    version
    1.0.0 1.0.1