Skip to main content
Glama
Sign In
kazaplan-mcp

kazaplan-mcp

by padupuy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Kz Open

kz_open

Opens a Kazaplan plan from the API via plan_id and KZ_TOKEN, or from a local .kzp path; local files get a backup copy before editing.

Instructions

Ouvre un plan : depuis l'API Kazaplan (plan_id, nécessite KZ_TOKEN) ou un fichier .kzp local (path). Pour un fichier local, plan_id (cible d'un futur kz_save) vaut par défaut le début du nom de fichier (« 12345678-20261014-212320-orig.kzp » -> « 12345678 »). Une copie de sauvegarde du .kzp d'origine est écrite dans backups/.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "kz_open"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNo
plan_idNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it does disclose two non-obvious traits: the KZ_TOKEN auth requirement for the API mode and the side effect of writing a backup copy of the original .kzp into backups/. It does not describe error behaviour or what happens to an already-open plan, leaving some behavioral surface undocumented.

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

Conciseness4/5

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

Three sentences, front-loaded with the core action and the source modes, followed by the default-derivation rule and the backup side effect. The parenthetical example earns its place, though the wording is slightly dense and mixes French prose with English tokens.

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?

Both parameters are explained at 0% schema coverage, the side effect is disclosed, and an output schema exists so return values need not be described. What remains thin is failure handling and the behaviour when neither source parameter is given, which matters for a tool with zero required parameters.

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 description coverage is 0%, so the description must compensate, and it does: path is identified as a local .kzp file and plan_id is explained both as the API identifier and as a value derived from the filename, with a concrete example ('12345678-20261014-212320-orig.kzp' -> '12345678'). It stops short of stating the accepted string format for an API plan_id.

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?

The description uses a specific verb ('Ouvre') and resource ('un plan') and immediately enumerates the two distinct sources: the Kazaplan API via plan_id or a local .kzp file via path. It also names the sibling kz_save as the consumer of the resulting plan_id, so an agent can place this tool relative to its neighbours without opening a schema.

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?

It clearly routes between the two modes: plan_id selects the API path (and states it requires KZ_TOKEN), path selects a local file. It references kz_save as the downstream tool for the derived plan_id, but does not state exclusions such as what happens if both parameters are supplied or neither is.

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

Deploy Server

Other Tools