Skip to main content
Glama
nmarijane

LightSpot MCP Server

by nmarijane

Create or update an editorial calendar

create_editorial_calendar

Import up to 50 dated editorial slots into a LightSpot calendar. Update without duplicates using externalId; it only creates the planning, no content generation or AI credits.

Instructions

Importe jusqu'à 50 créneaux éditoriaux datés dans le calendrier d'un site LightSpot. L'import est idempotent : externalId permet de mettre un créneau à jour sans doublon. Cette action crée uniquement le planning ; elle ne génère, ne planifie et ne publie aucun contenu et ne consomme aucun crédit IA.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYesCréneaux à afficher dans le calendrier LightSpot.
siteIdYesIdentifiant du site LightSpot.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses the 50-item cap, idempotent upsert semantics via externalId, and the absence of AI-credit consumption or content side effects. It stops short of stating whether slots absent from the batch are preserved or removed (merge vs replace) and says nothing about required permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: capability and limit first, then the idempotency mechanism, then the negative scope. No filler, and the most decision-relevant facts (limit, idempotency, no side effects) are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter write tool with no annotations and no output schema, the description covers limits, idempotency, and side-effect boundaries well. The remaining gap is the merge/replace semantics of a re-import and any permission requirements, which an agent would want before mutating a calendar.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: externalId is framed as the idempotency key that updates a slot instead of duplicating it, and items is characterized as 'créneaux datés'. This goes beyond the schema's field-level descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (import/upsert up to 50 dated editorial slots) and the exact resource (a LightSpot site's editorial calendar), which cleanly separates it from the read-only sibling get_editorial_calendar. The boundary statement ('creates only the planning') prevents confusion with content-generation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for use and strong negative scoping — it does not generate, schedule, or publish content and burns no AI credits, so an agent knows this is a pure planning call. It never names an explicit alternative tool, but no sibling competes for this write path, so the omission is minor.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.