Skip to main content
Glama
Sign In

METODIC

by io.metodic
OverviewDiscussionsAdmin

Design a session

design_session

Turn the conversation into a REAL session in the user's Metodic account: a timed agenda built from the method library, saved and ready to run, edit, share and export. Returns a session_id immediately and the Metodic card fills itself in about a minute — do not poll design_status yourself unless the client has no card. Costs 2 Metodic credits. This is the hand-off from chat to Metodic: after it, offer worksheets/handouts/documents or send the user to their session.

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": {
      "topic": "<topic>",
      "duration_minutes": "<duration_minutes>"
    },
    "name": "design_session"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoNumber of days (default 1). Set this whenever the user says two-day, three-day, multi-day or an offsite spanning several days — each day then gets its own opening, breaks and closing, and its own clock. Never express extra days as one long day.
goalNoThe purpose / desired outcome — pass the user's FULL brief verbatim (context, the client's own vocabulary, the named people and their tensions, the constraints, what must NOT happen). The Architect designs every block from this text; a one-line summary throws that away.
topicYesWhat the session is about (title or subject).
formatNoHow people take part: 'in-person', 'online' or 'hybrid'. Set it whenever the user says so (an online seminar, on Zoom, in our office): every step is written for that mode.
audienceNoAudience or experience level (e.g. 'beginners', 'leadership team').
languageNoISO code (en/nl/es/fr/de/pt/it/ja/zh). Default en.
frameworkNoOptional framework slug/name from list_frameworks.
format_slugNoOptional: the slug of a proven format from find_session_format. Seeds the design with that structure and records that the format was used — pass it whenever the user picked one.
participantsNoNumber of participants (default 12).
duration_minutesYesTOTAL session length in minutes, across all days (min 30). For a two-day programme of about 7 hours a day, that is 840.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / format / description
      Previous value: -"e.g. 'workshop', 'training', 'in-person', 'online'."New value: +"How people take part: 'in-person', 'online' or 'hybrid'. Set it whenever the user says so (an online seminar, on Zoom, in our office): every step is written for that mode."
  2. Changed1 schema field changed
    • changedInput schema / properties / language / description
      Previous value: -"ISO code (en/nl/es/ja/fr/de). Default en."New value: +"ISO code (en/nl/es/fr/de/pt/it/ja/zh). Default en."
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing the credit cost (2 Metodic credits), the asynchronous return behaviour (session_id immediately, card fills in ~a minute), and the polling exclusion. With readOnlyHint=false and idempotentHint=false already declared, the description correctly frames this as a non-idempotent write without contradicting anything. It stops short of saying what happens on failure or whether a retry double-charges credits, which matters for a paid, non-idempotent call.

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 action and outcome, then cost, then next steps — a sensible ordering with no filler sentences. Minor deduction for the emphatic 'REAL' capitalisation and a few stacked clauses that make it denser than it needs to be.

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

Completeness5/5

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

There is no output schema, and the description compensates by explaining exactly what comes back (a session_id immediately, contents about a minute later) and what the agent should do in the meantime. For a credit-charged, asynchronous creation tool with fully documented parameters, nothing an agent needs in order to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100% and the parameter descriptions are unusually rich — days vs. duration_minutes, verbatim goal text, format slugs from find_session_format — so the schema already does the heavy lifting. The tool description itself adds no parameter-level meaning; it only tells the agent to pass the full brief, which the goal parameter already states. Baseline 3 is appropriate.

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 ('turn the conversation into a REAL session... a timed agenda built from the method library, saved and ready to run') and implicitly separates itself from design_status and refine_session by describing the creation hand-off. An agent can tell this is the creation step, not the polling or editing step, without opening the schema.

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?

Gives explicit sequencing: this is the hand-off from chat to Metodic, and after it the agent should offer worksheets/handouts/documents or send the user to their session. It also names the condition under which the alternative (design_status polling) applies — only when the client has no card — which is a clean when/when-not rule.

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

All METODIC toolsInspect
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