Skip to main content
Glama

AestheticsPro by Cotlet

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 AestheticsPro it covers these actions: Search clients, Search leads, Add a client, View client contact details, Configure gender identity and pronouns, Apply client gender identity, View appointment calendar, View scheduling changes and availability, Create appointment, Modify appointment, View Book Now availability, Book an appointment online, Book through Client Portal, View appointment history, Configure Book Now, Configure Client Portal, Create staff calendar, Create room calendar, Add equipment, Map services to scheduling resources, Set appointment duration, Set staff schedule, Create schedule template, Notify client of an opening, Sync appointments to Google Calendar, Sync appointments to Apple Calendar, Schedule a virtual appointment, Configure appointment confirmations, Set appointment reminder timing, Choose reminder channel, Send automated appointment reminders, Read client texts, Send client text, Draft client communication with Kai, View lead list, Create lead, Segment leads, Assign lead, View Client/Lead Demographics, Export contacts to Constant Contact, View communication dashboard, View outreach calendar, Create email template, Create SMS template, Draft outreach campaign with AI, Customize outreach campaign, Create text list, Send SMS blast, Create email list, Schedule E-Blast, Enable Touchpoints, Draft client journey, Configure client journey, Activate client journey, Adjust scheduled outreach, View email and SMS engagement, View appointment reports, Create staff announcement, View client appointment history, Send review request.

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: AestheticsPro.
taskNoWhat the user wants done in the app, in their words.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description does add genuinely useful context beyond them: "Free, no browser session," which tells the agent this call costs nothing and does not open or occupy the browser. It does not say how large the returned method is or whether it is worth re-calling per task, which is the remaining behavioral gap.

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 first three sentences are well front-loaded and earn their place, but they are followed by a ~60-item enumeration of AestheticsPro actions that dominates the definition and duplicates what the tool presumably returns at call time. That list inflates the description enormously without changing how an agent selects or invokes the tool.

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 knowledge tool with no output schema, the description covers what is returned (browser choice, sign-in link, method, screens, menus, actions, notes, dedicated tools), the trigger point, the cost, and the out-of-catalog fallback. The main omission is whether the method should be re-fetched per task or cached, and the `task` parameter's effect on output.

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% — both `app` (name or Cotlet slug, default AestheticsPro) and `task` are documented in the schema itself. The description adds no further semantics for either parameter; it does not explain how `task` narrows the returned method or what happens when `app` is omitted. Baseline 3 applies.

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 a specific verb and resource — it returns guidance on how to work in an app via the Cloud Browser using Cotlet's browser tools — and enumerates what the guidance covers (browser choice, sign-in link, step-by-step method, screens, menus, actions, notes, dedicated tools). That is clearly distinguishable from the sibling browser action tools (cotlet_browser_click, cotlet_browser_navigate, etc.), though it never names those siblings explicitly.

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, actionable trigger, and "Works for any web app; one outside Cotlet's catalog gets the general method" sets the fallback expectation. It stops short of a when-not statement (e.g., after the method is already known or for a second task in the same app), leaving some inference to the agent.

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