Loading ToolBench
MCP server for InfoSlides - a platform for managing digital signage, screens, slideshows, and dynamic content with live data integration
InfoSlides.MCP demonstrates solid tool definition quality with comprehensive descriptions and proper parameter annotations. All 25 tools have clear, action-verb names and detailed descriptions (avg ~180 chars, within baseline 194). Parameter descriptions are present and contextual. However, input schemas are inferred from C# attributes rather than explicitly visible in JSON Schema format, the code shows [Description] attributes and parameter types, but no explicit JSON Schema objects are rendered in the source. Output schemas are not documented. Error handling is present but generic (ToolResults.ValidationError, ToolResults.Execute) without recovery guidance. Tool composition is excellent, each tool has a single responsibility, and chaining is well-designed (e.g., create_device → assign_schedule → get_stream_link). Security is strong: no credentials in parameters, API key injection via constructor. Naming is consistent (verb_noun pattern) and unambiguous across all 25 tools.
Add a slide that keeps itself up to date instead of showing a fixed picture — today's soup, the current queue number, live sales figures, tomorrow's weather. Needs a template first (see create_template or list_templates). The slide starts empty; push the actual values in with update_source.
Put a picture or a video on the screen — a photo of the specials board, a poster, a promo clip, a logo. Takes either a publicly reachable URL (downloaded server-side) or the id of a file already in the media library (see upload_media); provide exactly one. If the picture's shape does not match the screen's, the call still succeeds but returns an AspectMismatch warning — fix it rather than letting content be stretched or cropped on a display the public can see.
Tell a screen what to play. Connects slideshows to a registered display, in the order given, as a continuous loop. The call succeeds even when the content's shape does not match the screen's, but returns an AspectMismatch warning — act on it, because it means the content will be stretched or cropped on a display people can see. Follow with get_stream_link to get the URL to open on the TV.
Copy an existing deck so it can be customised without touching the original — or, with fromGallery=true, start from a ready-made professional design instead of a blank screen. Cloning from the gallery is the fastest way to get something presentable on a TV; call list_gallery first to see what is available.
Input schemas not explicitly visible as JSON Schema objects in source code. Schemas are inferred from C# [Description] attributes and parameter types, but no explicit JSON Schema definitions are rendered. This makes it impossible to verify schema completeness, format constraints, enums, or min/max bounds at the protocol level.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Issue a credential so another system or person can work with this workspace. Type 'admin' grants full access — use it sparingly. Type 'dataProvider' creates a locked-down push-only key tied to named slides that can do nothing except feed those slides new values via update_source: the right choice when a till system, CRM, or script needs to keep one number on the screen current, because a leaked key cannot read or change anything else. The full key is shown once and never again — tell the user to store it somewhere safe.
Register the physical screen the content will play on — the TV in reception, the menu board above the counter, the noticeboard in the corridor, the display in the waiting room, the monitor in the shop window (Icelandic: upplýsingaskjár, skjár). Do this once per screen. Free accounts allow exactly 1 active screen; a DeviceLimitReached error comes with an upgrade link. Resolution defaults to 1920x1080 for a normal wall-mounted TV — use 1080x1920 for a screen turned on its end, which is common for menu boards and window displays.
Design a screen layout that fills itself in from live data, so the display stays current without anyone editing it — today's soup and price, the current exchange rate, a live sales counter, the next departure time. Requires a paid plan. Two ways to build it: describe the look in 'prompt' and give an example of the data in 'sampleJson', or hand over finished 'html' with {{field}} placeholders plus optional 'css'. The example data defines the shape every later update_source push must match. Set dryRun=true to check it without creating anything.
Start here when someone wants content on a TV or screen but has no InfoSlides account yet — a café putting its menu on a screen, a hotel with a lobby display, a school noticeboard, a shop window. Sets up their workspace and returns the Primary Admin API Key used by every later call. This is the only tool that needs no credentials. The new account lands on the permanent free plan: 1 screen, 4 slideshows, no credit card, nothing expires. A verification email goes to the owner and a few tools stay locked until they click it.
Find out whether a screen is actually on and what it is showing right now — is the TV live, when did it last check in, which content is playing. This is the tool to reach for when someone says the screen is blank, frozen, or showing the wrong thing.
Look inside one piece of screen content: every slide, the order they play in, how long each is shown, and any rules about when they appear. Use this before editing so you know what is already there.
Get the link that makes the content appear on the TV — the last step of any setup. Hand over playerUrl: opened in the smart TV's browser or the InfoSlides TV app, it plays the content correctly whichever way this screen is set up to play — the usual rendered-video stream or a live HTML/CSS loop. hlsUrl is the raw HLS manifest for something that only speaks HLS (an ffplay-style player, an old TV app build); it comes back null whenever the screen is playing an HTML loop, so check it before handing it out — do not assume it is always populated. The links are stable, so the screen keeps working as content changes. A StreamNotReady warning means nothing is playable yet — usually because the content is still rendering.
Check what this account is allowed to do before planning any screen work: workspace name, owner, whether their email is confirmed, which plan they are on, how many screens are in use out of the allowance, and the scope of the API key in use. Call this early — designing around the limits beats discovering them through errors halfway through a setup.
Audit who and what can reach this workspace: every key with its scope, when it was created, and when it was last used. Only the opening characters of each key are shown, never the whole thing. Use it to spot unused keys worth revoking, or to find the id of a key to revoke.
See every screen registered to this workspace and the shape each one is set up for. Use it to find the id of a screen before assigning content to it, or to check how many of the account's allowed screens are already used.
Browse ready-made screen designs — menu boards, welcome screens, notice layouts — that can be copied into the workspace with clone_slideshow(fromGallery=true). Start here when the user wants something on a screen quickly and has no content prepared.
See everything this workspace can put on a screen, with the shape (landscape or portrait) each one is built for. Use it to find the id of existing content before editing it or assigning it to a display.
See the self-updating screen layouts available to this workspace, each with an example of the data it expects. Check that example before pushing values with update_source, and use this to find a ready-made layout instead of building one.
Send the owner's confirmation email again. Use this when another tool fails with EmailNotVerified — the owner has to click the link in that email before screens can be registered. Tell the user to check their spam folder.
Cut off a credential immediately — a leaked key, a system being decommissioned, someone who has left. Takes effect at once and cannot be undone; anything still using that key stops working, so confirm with the user before revoking.
Change what is already playing on a screen: rename it, switch it between landscape and portrait, reorder the slides, or force how it plays. Pass slideOrder as the complete list of slide ids in the sequence you want them shown. playbackMode overrides the usual rendered-video stream with a smooth HTML/CSS loop (or back again) for this one slideshow; pass "inherit" to drop the override and go back to whatever the workspace normally uses.
Put fresh information on the screen: send today's menu, the new price, the current total, the updated opening hours. The display re-renders itself server-side — nobody has to touch the TV. The data must match the shape the template's example defines (see list_templates). This is also the only tool a restricted push-only (isk_dp_) key can call, which is how an external system safely feeds one slide. Set dryRun=true to check the data without changing what is on screen.
Get the checkout link when the free plan runs out — a second screen is needed, or the user wants self-updating slides fed by live data. Hand the link to the user to open; the extra capability unlocks by itself once payment goes through. Reach for this after a DeviceLimitReached or EntitlementRequired error rather than telling the user the thing cannot be done.
Send a picture or video from the user's own computer to their workspace — a photo of the specials board, a poster, a logo, a promo clip. Use this when the file is local and has no public web address. Returns an asset id; pass it to add_media_slide as mediaAssetId to put it on the screen.
Put an existing PowerPoint or PDF on a screen. Uploads a .pptx or .pdf from the local disk and turns it into screen content — the server reads the slide/page count and the file's own resolution and starts rendering it into a video stream. This is usually the quickest route when the user says they already have a presentation or a PDF deck.
Create the content that will play on a screen — the lunch menu, this week's offers, opening hours, staff notices, a welcome message for a hotel lobby. A slideshow is a deck of slides that loops on the display. Resolution defaults to 1920x1080 for a normal wall-mounted TV; use 1080x1920 for a portrait screen standing on its end, which is common for menu boards and shop windows. Slides can be added inline here or later with add_media_slide.
Output schemas not documented. Tools return results via ToolResults.Execute() with JSON context references (e.g., InfoSlidesJsonContext.Default.CreateApiKeyResult), but the actual response structure is not visible in the provided source. LLMs cannot plan downstream tool calls without knowing what fields are returned.
Error handling is generic and lacks recovery guidance. ToolResults.ValidationError() and ToolResults.Execute() catch exceptions but do not provide actionable next steps. For example, when create_device fails with DeviceLimitReached, the error should include the upgrade link and suggest calling upgrade_subscription.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in the MCP protocol output. The C# code uses [McpServerTool(ReadOnly=true, Destructive=true)] attributes, but it is unclear whether these are serialized into the MCP tool definition's annotations field for the client.
Pagination not visible for list_* tools. list_api_keys, list_devices, list_slideshows, list_templates, and list_gallery do not show limit, offset, or cursor parameters in the provided schema. If these tools return unbounded lists, they risk exhausting context windows.