Skip to main content
Glama
Sign In

Agency Autopilot

by com.jiyumarketing.mcp
OverviewDiscussionsAdmin

Agreements: draft an agreement for a prospect or client (live preview, nothing sent)

agreement_draft

Draft a service agreement to sign and pay. Offer it when a prospect says yes (from find_prospects / prospect_drafts) or when the agency wants to sign a client. Plain words: client = the business name or website as the agency says it (it fills the address, phone, website and email from the agency's prospect searches, clients, or CRM with crm_location_id; it never invents a person or an email); services in plain words ("SEO", "Google Ads", "website", or anything else); monthly and one_time prices in DOLLARS as the agency agreed them. With no price named, its saved offer is used (ask which if unsure); NEVER guess a price. Uses the standard agreement unless the agency saved its own wording: nothing to set up. Returns drafted:false with ONE short list of questions when it must ask (a price, the governing state once, which prospect). Otherwise a live preview link with a Send button. Nothing is sent.

Input Schema

NameRequiredDescriptionDefault
crmNoThe deal in the agency's CRM, marked won once paid
clientYes
monthlyNoMonthly price in dollars, as agreed
one_timeNoOne-time / set-up price in dollars, as agreed
servicesNoPlain words, e.g. ["SEO", "Google Ads"]; leave out to use the agency's offer
client_idNoAn existing Autopilot client this is for (list_clients)
line_itemsNoOnly for a more detailed price list (CENTS); otherwise use monthly / one_time
start_dateNoYYYY-MM-DD of the first monthly charge; leave out to start at signing
term_monthsNoInitial term in months; leave out for month to month
contact_nameNoThe person who signs, only if the agency said it
custom_termsNoAnything special agreed for this deal, one item each
contact_emailNoWhere it goes, only if known (it can be added later; sending needs it)
contact_phoneNo
email_messageNoThe email's message to the client, in the agency's words
crm_location_idNoThe agency's own HighLevel sub-account to look the contact up in
governing_stateNoOnly when asked: the state whose law applies (saved for next time)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed23 schema fields changed
    • addedInput schema / properties / client / anyOf
      Added value: +[
+  {
+    "description": "Business name or website, as the agency says it",
+    "maxLength": 200,
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "properties": {
+      "address": {
+        "maxLength": 240,
+        "type": "string"
+      },
+      "company": {
+        "maxLength": 140,
+        "type": "string"
+      },
+      "email": {
+        "maxLength": 200,
+        "type": "string"
+      },
+      "name": {
+        "maxLength": 120,
+        "type": "string"
+      },
+      "phone": {
+        "maxLength": 40,
+        "type": "string"
+      },
+      "website": {
+        "maxLength": 200,
+        "type": "string"
+      }
+    },
+    "type": "object"
+  }
+]
    • removedInput schema / properties / client / properties
      Removed value: -{
-  "address": {
-    "maxLength": 240,
-    "type": "string"
-  },
-  "company": {
-    "description": "The client's business name (becomes the Autopilot client's name once paid)",
-    "maxLength": 140,
-    "type": "string"
-  },
-  "email": {
-    "description": "Where the agreement goes",
-    "maxLength": 200,
-    "type": "string"
-  },
-  "name": {
-    "description": "The client's contact person",
-    "maxLength": 120,
-    "minLength": 1,
-    "type": "string"
-  },
-  "phone": {
-    "maxLength": 40,
-    "type": "string"
-  },
-  "website": {
-    "maxLength": 200,
-    "type": "string"
-  }
-}
    • removedInput schema / properties / client / required
      Removed value: -[
-  "name",
-  "email"
-]
    • removedInput schema / properties / client / type
      Removed value: -"object"
    • changedInput schema / properties / client_id / description
      Previous value: -"An existing Autopilot client this agreement is for (list_clients); leave out for a new client, created once they pay"New value: +"An existing Autopilot client this is for (list_clients)"
    • addedInput schema / properties / contact_email
      Added value: +{
+  "description": "Where it goes, only if known (it can be added later; sending needs it)",
+  "maxLength": 200,
+  "type": "string"
+}
    • addedInput schema / properties / contact_name
      Added value: +{
+  "description": "The person who signs, only if the agency said it",
+  "maxLength": 120,
+  "type": "string"
+}
    • addedInput schema / properties / contact_phone
      Added value: +{
+  "maxLength": 40,
+  "type": "string"
+}
    • addedInput schema / properties / crm_location_id
      Added value: +{
+  "description": "The agency's own HighLevel sub-account to look the contact up in",
+  "maxLength": 80,
+  "type": "string"
+}
    • removedInput schema / properties / currency
      Removed value: -{
-  "description": "Default usd",
-  "maxLength": 3,
-  "minLength": 3,
-  "type": "string"
-}
    • removedInput schema / properties / effective_date
      Removed value: -{
-  "description": "YYYY-MM-DD; leave out for the signing date",
-  "type": "string"
-}
    • removedInput schema / properties / email_subject
      Removed value: -{
-  "maxLength": 140,
-  "type": "string"
-}
    • addedInput schema / properties / governing_state
      Added value: +{
+  "description": "Only when asked: the state whose law applies (saved for next time)",
+  "maxLength": 60,
+  "type": "string"
+}
    • addedInput schema / properties / line_items / description
      Added value: +"Only for a more detailed price list (CENTS); otherwise use monthly / one_time"
    • removedInput schema / properties / line_items / minItems
      Removed value: -1
    • addedInput schema / properties / monthly
      Added value: +{
+  "description": "Monthly price in dollars, as agreed",
+  "maximum": 1000000,
+  "minimum": 0,
+  "type": "number"
+}
    • addedInput schema / properties / one_time
      Added value: +{
+  "description": "One-time / set-up price in dollars, as agreed",
+  "maximum": 1000000,
+  "minimum": 0,
+  "type": "number"
+}
    • changedInput schema / properties / services / description
      Previous value: -"Optional sections of the template to include, e.g. [\"seo\",\"ads\",\"web\"]"New value: +"Plain words, e.g. [\"SEO\", \"Google Ads\"]; leave out to use the agency's offer"
    • changedInput schema / properties / services / items / maxLength
      Previous value: -40New value: +80
    • changedInput schema / properties / services / maxItems
      Previous value: -10New value: +8
    • changedInput schema / properties / term_months / description
      Previous value: -"Initial term in months"New value: +"Initial term in months; leave out for month to month"
    • removedInput schema / properties / values
      Removed value: -{
-  "additionalProperties": {
-    "maxLength": 500,
-    "type": "string"
-  },
-  "description": "Values for any other {{placeholder}} the template uses, for this deal",
-  "propertyNames": {
-    "type": "string"
-  },
-  "type": "object"
-}
    • changedInput schema / required
      Previous value: -[
-  "client",
-  "line_items"
-]New value: +[
+  "client"
+]
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that nothing is sent, that a preview link with a Send button is produced, that the response may be drafted:false with a single consolidated question list, that client details are filled from prospect searches/clients/CRM rather than invented, and that prices are never guessed. This tells the agent the failure/ask behavior, which annotations cannot express.

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 purpose, then usage, then parameter rules, then return behavior — a sensible order for a 16-parameter tool. It is somewhat long and repeats the no-guessing rule twice ('ask which if unsure; NEVER guess a price'), but almost every sentence carries operative guidance.

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?

For a 16-param, nested-object tool with no output schema, the description still explains what comes back (preview link, or drafted:false with questions) and covers the required client resolution path plus pricing fallbacks. Nothing an agent needs in order to call it correctly or interpret the result is missing.

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 88%, so baseline is 3, but the description adds real meaning to the ambiguous required param: 'client' can be a plain business name/website that gets resolved against the agency's prospect searches, clients, or CRM via crm_location_id, and it explains that monthly/one_time are DOLLARS as agreed and fall back to the saved offer. It also clarifies governing_state is only supplied when asked. Remaining params (line_items, term_months, start_date) are left to the schema.

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?

Opens with a specific verb+resource ('Draft a service agreement to sign and pay') and immediately contrasts the outcome with sending ('live preview link with a Send button. Nothing is sent'), which separates it from agreement_send, agreement_update and agreement_offer_save. An agent can identify the tool and its boundary 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 Guidelines4/5

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

Gives explicit triggers: 'Offer it when a prospect says yes (from find_prospects / prospect_drafts) or when the agency wants to sign a client.' Upstream siblings are named. It stops short of stating when NOT to use it (e.g., use agreement_send to actually send, agreement_update to revise an existing draft), leaving that 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.

All Agency Autopilot 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