Skip to main content
Glama

Exercise.com by Cotlet

Publish an assessment for clients in Exercise.com

exercise_com_publish_an_assessment_for_clients
Read-onlyIdempotent

Publish an assessment for clients in the user's own Exercise.com account from ChatGPT, Claude or any AI agent. Returns how to do it in Exercise.com step by step (screens, buttons, fields) and opens nothing by itself; then do it with the cotlet_browser_* tools in the user's Exercise.com Cloud Browser. Exercise.com's official API: Exercise.com has an official API as a paid add-on: "API access is an additional feature with variable pricing", quoted by your Account Representative for your intended usage (checked 11 Nov 2026).

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": "exercise_com_publish_an_assessment_for_clients"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false and idempotentHint=true, and the description reinforces this by stating the tool opens nothing and only returns instructions. It also adds genuinely useful context not in the annotations: the step-by-step return format (screens, buttons, fields) and the note that API access is a separately priced add-on.

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

Conciseness3/5

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

The core workflow is front-loaded and easy to act on, but the trailing API pricing sentence is long and only tangentially related to invoking this tool, and its date reference adds noise. Trimming or moving that to a note would improve density.

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?

With no parameters and no output schema, the description carries the burden of explaining what comes back, and it does so (step-by-step screens, buttons, fields). The agent also learns the follow-up path via the browser tools, so an agent has enough to invoke it correctly.

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?

The tool takes zero parameters, which is the correct baseline of 4. The description is consistent with a no-argument tool and adds no misleading parameter expectations.

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

Purpose4/5

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

The description states a specific verb and resource (publish an assessment for clients) and immediately clarifies the actual mechanics: it returns step-by-step instructions rather than performing the action. That resolves the ambiguity in the tool name, though it does not explicitly differentiate itself from sibling assessment tools such as the field/scoring editor or the assign/send variants.

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 gives clear operational guidance: the tool opens nothing by itself, and the follow-up action is performed with the cotlet_browser_* tools in the user's Exercise.com Cloud Browser. What's missing is any explicit exclusion or comparison against sibling tools, so the agent must infer when to prefer this over e.g. the assignment or creation tools.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources