Skip to main content
Glama
Sign In

CoachingPortal by Cotlet

by dev.cotlet
OverviewDiscussionsAdmin

Cotlet: how to work in an app

cotlet_app_guide
Read-onlyIdempotent

How to work in an app by clicking in the user's Cloud Browser with Cotlet's browser tools: which browser to use for this workspace and the sign-in link, the method step by step, the app's screens, menus and actions, notes, and the app's dedicated tools when Cotlet has them. Call it before the first browser step in an app. Works for any web app; one outside Cotlet's catalog gets the general method. Free, no browser session. For CoachingPortal it covers these actions: List clients, Get client progress, Invite client, Review application, Edit intake form, Publish intake form, Set client active, Add progress entry, Adjust client targets, Update client tracking, List check ins, Respond to check in, Append check in note, List check in schedule, List programs, Create program template, Edit program template, Assign program, List meal plans, Create meal plan, Assign meal plan, Manage recipe book, Assign recipe book, List habits, Configure client habit, List messages, Send message, List community, Create team chat, Publish challenge, Create leaderboard, Get coaching analytics, List resources, Add resource, Attach client resource, List coaches, Invite coach, Set calculation defaults, Configure check in questions, Publish announcement, Duplicate program, Share program, Manage custom exercise, Manage workout block, Edit meal plan, Manage coach invitation, Reassign coach clients, Generate check in draft, Create progress story, Set adherence weights, Set weight tracking policy, Get dashboard, Remove client invitation, Delete client, Update client profile metrics, Manage movement screen, Search exercises, Delete program template, List workout blocks, Duplicate meal plan, Share meal plan, Delete meal plan, Calculate meal plan targets, List recipe books, Delete recipe book, Search food library, Import food to plan, Favorite food, Generate progress summary, Generate training draft, Generate meal plan draft, Discard ai draft, Get ai credit balance, Get coach referrals, List pt sessions, Manage pt session, Log pt workout, Update workspace branding, Manage landing page, Update coach profile, Set workspace units, Get subscription, Manage subscription, Submit feature request, Delete workspace or account, Get personal insights, Log personal progress, Manage personal food log, Log recipe today, Get grocery list, Read meal recipe, Manage personal workout, Create workout share image, Submit personal check in, Log habit completion, Manage self coaching habits, Manage challenge membership, Refresh leaderboard, Upload progress photo, Update personal profile, Configure training summary email, Dismiss announcement, Manage self coaching plan, Cancel challenge, Send voice message, Open pt join code, Set notification preferences, Manage connected accounts.

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

Input Schema

NameRequiredDescriptionDefault
appNoThe app's name or Cotlet slug. Default: CoachingPortal.
taskNoWhat the user wants done in the app, in their words.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is low, and the description adds genuinely non-obvious facts beyond them: "Free, no browser session" tells the agent this call costs nothing and opens no live session. It also discloses the shape of what comes back (method, screens, notes, dedicated tools) rather than leaving the return implicit. It does not describe size or format of the payload, which keeps it off a 5.

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

Conciseness2/5

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

The purpose and the call-timing rule are correctly front-loaded, but roughly 85% of the text is an exhaustive dump of CoachingPortal action names that no agent needs in order to decide to call this tool. That list is a documentation artifact, not selection guidance, and it pushes the actionable instruction far from the end of a very long string.

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 read-only guidance tool with no output schema and only two optional parameters, the description covers what it returns, when to call it, its cost, and its fallback for uncatalogued apps. The only real omission is any hint about how the returned guidance should be sequenced against the browser_* tools beyond the single "before the first step" rule.

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 coverage is 100% and both parameters are documented in the schema, so the baseline is 3. The description adds one useful semantic point the schema does not: an app outside the catalog still returns the general method rather than failing. The task parameter is never addressed, so no further credit is earned.

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 opening clause names the resource (a per-app usage guide) and the subject matter it returns: which browser, sign-in link, step-by-step method, screens, menus, actions, notes, and dedicated tools. That is specific enough to separate it from the sibling browser_* primitives, which perform clicks rather than explain them. The purpose is clear but the following 100+ item action list dilutes the signal and makes the first sentence do less work than it should.

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?

"Call it before the first browser step in an app" is an explicit trigger condition, and "Works for any web app; one outside Cotlet's catalog gets the general method" pre-answers the fallback question. There is no explicit when-not or named alternative, so it stops short of full routing guidance, but an agent will not misorder this call.

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

All CoachingPortal by Cotlet 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