Conciergr Timetable

Read a Conciergr Timetable skill

get_skill

Read-only

Read one of Conciergr Timetable's skills: step-by-step instructions for a bigger job, written by the team that builds it. Before starting one of these jobs, read its skill and follow it:

import-timetable: Move a class business's whole timetable into Conciergr Timetable from wherever it lives now (a Google Sheet or Excel file, a PDF, a photo, a website page, a booking system export), check every class against the source, and hand over a clean timetable ready to go live. Use when setting up a new timetable, when moving classes over from a spreadsheet or another system, or when the owner sends a timetable file and asks to load it.
keep-timetable-current: Keep a Conciergr Timetable right through the year so families and the business's assistant always get the true answer - seats after enrolments, closed days and holidays, a cancelled lesson, a class moving day or time, a class ending, fee changes, and rolling the timetable into the next term or year. Use when the owner reports any change to their classes, for a weekly or end-of-term check, or when the timetable says a run of classes is ending. A skill may name further files of its own (such as references/checklist.md); read one by passing it as file.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

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

Input Schema

Name	Required	Description	Default
`file`	No	A file the skill names, such as references/checklist.md. Leave out for the skill itself (SKILL.md).
`name`	Yes	The skill to read.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: skills can name their own nested files and those are read by passing the path as `file`, which an agent would not infer from the annotations alone. It stops short of describing the returned content format, which is the only notable gap.

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?

Front-loaded with the core purpose, then structured as a bullet list keyed by skill name, so the agent can scan to the relevant entry. The bullets are long and clause-heavy, but each clause is a distinct usage trigger rather than filler; only minor tightening is possible.

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 read-only tool with no output schema, the description covers what the tool returns conceptually (procedural instructions), which skills exist, and how to fetch sub-files. The one omission is that it never states the response is text/markdown content rather than structured data, which would help set expectations.

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% and both parameters carry their own descriptions, so the baseline is 3. The description still earns credit by enumerating the exact valid `name` values and their scope, and by explaining the nested-file mechanism for `file` (references/checklist.md) with the default being SKILL.md, which is meaning beyond the schema text.

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 and resource ('Read one of Conciergr Timetable's skills') and defines what a skill is ('step-by-step instructions for a bigger job'). The bulleted enumeration of the two skills, import-timetable and keep-timetable-current, makes it unmistakable which resource this tool exposes versus the operational siblings like add_classes or change_class_time.

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

Usage Guidelines5/5

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

Explicitly says 'Before starting one of these jobs, read its skill and follow it', then gives concrete trigger conditions for each skill (setting up a new timetable, migrating from a spreadsheet, owner reports a change, end-of-term check). This is a clear when/when-not rule that routes the agent before it touches the sibling tools.

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

All Conciergr Timetable tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?