Which integrations are available for this server?

Provides tools for managing leads and marketing data through the HubSpot CRM. Enables interaction with QuickBooks for accounting tasks and financial data management.

How do I use BackCrew GorillaDesk MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BackCrew GorillaDesk MCP Server list all customers with lead status" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

BackCrew GorillaDesk MCP Server

by jayson-svg

Overview Schema Source Related Servers Discussions Admin

TypeScript

BackCrew GorillaDesk MCP Server

Think of this like a brand-new employee on their first day, not a business partner.

A new hire only does the exact tasks you've shown them, nothing more, until you decide they're ready for more responsibility. That's the idea behind this project: it connects an AI assistant like Claude or ChatGPT to your GorillaDesk account, so you can ask for things in plain English instead of clicking through the GorillaDesk app yourself.

One honest difference from the rest of this series, up front: GorillaDesk's own public tools don't yet let us build the "responsibility levels" the other BackCrew MCP servers have (more on that below), so for now, this one really is more all-or-nothing once you hand it a key. Read How this keeps you safe before you set it up.

Built by BackCrew, part of a series of free tools like this for the software pest control companies use every day.

Not a developer? That's fine. Everything up through "Testing it safely" is written for you: no coding background needed, and no computer jargon without an explanation first.

Related MCP server: gorgias-mcp

What this actually does

Let's be upfront about what this is, because it's easy to oversell: it's not some all-knowing assistant that understands your business and runs things for you. It's a specific, named list of actions that an AI assistant is allowed to trigger when you ask in plain English. It doesn't have judgment about your business. It just matches what you ask for to the closest thing on its list and does exactly that. Nothing more.

Once it's running, you can ask things like:

"Find the customer record for Dana Ruiz and add a note that she prefers afternoon appointments."
"List every lead-status customer we've added this month."
"Who are our technicians, and what's Mike's license number?"

And it does the clicking for you: the same actions you'd take yourself, just faster, in plain English.

Why use an independent MCP server instead of the platform's own AI?

Software platforms are increasingly shipping their own built-in AI features. Worth knowing why you might still reach for this instead:

No plan-tier gates. Native AI features are often locked to a platform's most expensive plan. This project just needs API access, which is usually available on lower tiers too.
Cross-platform, not walled off. A platform's own AI only sees that platform's own data; it has no reason to work fluently with your accounting software, another CRM, or your email, since those are somebody else's product. An MCP-connected assistant can have multiple servers attached at once (this one plus another BackCrew server covering a different part of your business), so it can work across your whole stack in one conversation.
Your choice of AI, not theirs. You keep using whichever assistant you already trust (Claude, ChatGPT, whatever) instead of learning a new vendor-specific AI interface.

What this server can't do yet (read this before you get your hopes up)

Be upfront about this: GorillaDesk's public tools are small right now. This server covers 9 actions across 5 areas: Company info, Users, Customers, Customer Notes, and Phone Types.

That's it. There's currently nothing public for jobs, scheduling, invoicing, estimates, technician routes, materials, or leads as their own thing, even though GorillaDesk the product clearly has all of that. Either the rest sits behind a bigger-account tier that isn't publicly documented, or it just hasn't been opened up yet.

We're shipping this at its true, honest size instead of padding it with guessed-at features that don't actually work. If GorillaDesk opens up more, this server (and this README) grows with it. See What's next.

You don't need a GorillaDesk account just to look at this project or try it out. It starts up and shows you everything it can do with zero setup; it only asks for your GorillaDesk key once you actually try to use it on your real account.

Also from BackCrew

This is one of several MCP connectors BackCrew builds, same idea, different software. We've also got QuickBooks for the accounting side, plus CRM connectors like HubSpot and GoHighLevel for lead and marketing data. Full list and what's live right now: see ROADMAP.md.

Beyond this repo: once a business gets comfortable with an AI assistant reading its data, there's often more it wants to do with it, like catching missed calls faster, processing invoices and paperwork automatically, following up on quotes without someone having to remember, reactivating customers who've gone quiet, or pulling reports without digging through the software. That's a separate, scoped conversation, not part of this free, open-source repo. Same contact as in Built by BackCrew below if it's something you want to explore.

Some words you'll see, explained

API: short for "Application Programming Interface." A locked door into GorillaDesk's data that only software (not a person clicking a mouse) can open. This project is a key that opens that door.
MCP: short for "Model Context Protocol." The standard way an AI assistant like Claude or ChatGPT is told "here's exactly what you're allowed to do, and how to do it." This project speaks that standard, which is why it plugs into Claude (and similar tools) with no custom setup.
Server: a small program that sits between your AI assistant (Claude, ChatGPT, etc.) and GorillaDesk, translating requests back and forth. You start it once and leave it running; you never interact with it directly.
Repo (short for "repository"): the folder of code for this whole project. "Clone the repo" just means "download a copy of this project."
API key: a long, private password-like code that proves a request is really coming from you. You'll generate one from your own GorillaDesk account (steps below) and never share it.
Terminal: a plain-text window on your computer where you type commands instead of clicking buttons. We walk you through this step by step.
Tool: one specific action the AI is allowed to take. Each one is listed and named individually; there's no hidden catch-all action.

How this keeps you safe

Here's the honest version, not the sales version: the other servers in this series can be dialed down to "look only" mode with a couple of settings, and even when you turn on more, you pick exactly how much. GorillaDesk's public tools don't give us enough to build that same dial for this one yet: once you hand this server your GorillaDesk key, it can do anything that key is allowed to do (which, given the small scope above, is mostly customer records and notes; there's no invoicing or job-deletion risk here regardless).

What that means in practice:

Treat your GorillaDesk key with extra care: it's the only thing standing between "just looking things up" and "changing customer records."
If you only ever want to look things up and never write anything, the honest way to do that today is simple: just don't ask the AI to create or update anything. There's no software switch to flip yet.
We'll add the same tiered read-only-by-default system the rest of this series has the moment GorillaDesk's public tools support it. See What's next.

What it can do

What it covers	Examples
Company	View your company info
Users	View your team members
Customers	Search, view, create, and update customer records
Customer Notes	Add a note to a customer's record
Phone Types	View the phone number types your account uses

9 actions in total. See What this server can't do yet for what's missing.

How to set it up

Do these three steps in order. Each one gathers everything you need before you move to the next. You won't have to jump back and forth.

Step 1: Make a folder for this on your computer

Before touching anything technical, just pick a spot and create an empty folder.

Open Finder (Mac) or File Explorer (Windows)
Go to your Desktop or Documents, anywhere easy to find again
Create a new folder and name it something like backcrew-gorilladesk

That's it. You now know exactly where this project is going to live. Keep this Finder/Explorer window handy: you'll need to find this folder again in Step 3.

Step 2: Get your GorillaDesk key

Do this next, entirely inside GorillaDesk (no terminal yet).

Log into your GorillaDesk account
Click Addons in the menu
Click API
Generate a key
Copy the key, then paste it somewhere temporary (a Notes app, a blank email draft) so you don't lose it before Step 3

Full details, if you want a second reference: GorillaDesk API authentication docs.

You now have everything GorillaDesk needs to give you. Time to move to the terminal.

Step 3: Install it

This is one continuous set of steps: do them in order, in the same terminal window.

Open a terminal. On a Mac, press Cmd + Space, type "Terminal," and hit enter. On Windows, click the Start menu, type "PowerShell," and hit enter. Use PowerShell rather than Command Prompt: a couple of the commands below, like pwd, only work in PowerShell.
Move into the folder you made in Step 1. Type cd (with a space after it), then drag your backcrew-gorilladesk folder from Finder/Explorer straight into the terminal window (it'll fill in the full path for you), then press Enter.
Download the project into that folder. Paste this exactly and press Enter:
```
git clone https://github.com/jayson-svg/backcrew-mcp-gorilladesk.git .
```
(The period at the end matters: it downloads into the folder you're already in, instead of making a new one. If your computer asks to install "command line developer tools" the first time you use git, say yes, that's normal on a Mac that's never used git before.)
Install what the project needs to run. Paste and press Enter:
```
npm install
```
Get it ready to use. Paste and press Enter:
```
npm run build
```
Get the folder's exact location (you'll need this in Step 4). Paste and press Enter:
```
pwd
```
This prints something like /Users/yourname/Desktop/backcrew-gorilladesk. Copy that whole line: you'll paste it into Claude's settings next.
Create your settings file. Paste and press Enter:
```
cp .env.example .env
```
Open that new file in a text editor. On a Mac: type open -e .env and press Enter. On Windows: type notepad .env and press Enter.
Paste in the key you copied in Step 2. Find the line that says GORILLADESK_API_KEY= and paste your key right after the =, no spaces.
Save the file and close it. (Cmd+S / Ctrl+S, then close the window.)

That's the whole install. Keep that pwd output from step 6 handy: the next section uses it.

Connecting it to Claude

This step comes last on purpose: it needs the exact folder location from Step 3, and now you have it.

Claude Desktop / Claude Code

Open Claude's settings file. For Claude Desktop, this is claude_desktop_config.json; Claude's own settings menu will show you where to find it.
Add this, replacing PASTE_YOUR_PWD_OUTPUT_HERE with what pwd printed in Step 3.6, and your_key_here with your GorillaDesk key again. If you're on Windows, swap any backslashes in that path for forward slashes (for example C:/Users/yourname/Desktop/... instead of C:\Users\yourname\Desktop\...), since the config file needs regular slashes.

{
  "mcpServers": {
    "gorilladesk": {
      "command": "node",
      "args": ["PASTE_YOUR_PWD_OUTPUT_HERE/dist/index.js"],
      "env": {
        "GORILLADESK_API_KEY": "your_key_here"
      }
    }
  }
}

Save the file and restart Claude completely (quit it, don't just close the window).

You should now see GorillaDesk show up as something Claude can use. Nothing more to do: no need to go back to GorillaDesk or the terminal.

This also works with ChatGPT and other MCP-compatible AI tools (Cursor, Windsurf, and others); the setup step is basically the same.

Things you can try asking

"Show me every customer with status 'lead' created in the last two weeks"
"Look up the customer with account number 5047 and pull up their locations"
"Add a note to that customer's account saying the gate code changed, and notify Mike"
"List our technicians and who has admin access"

It's not useful yet for job scheduling, invoicing, or estimates; GorillaDesk hasn't opened up public endpoints for those.

Testing it safely

Given there's no dial to turn down yet, a few habits matter more here than in the rest of this series:

Get a feel for it on read-only-style questions first: just don't ask it to create or update anything until you trust how it interprets your requests.
The first time you do let it write something, test on a clearly fake customer. Make a test customer named something obvious like "ZZZ Test Customer: Do Not Use" and see how that goes before pointing it at a real one.
Never share your API key: not in chat, not in a screenshot, not in a support ticket. Treat it like a password, because it functions like one.
If you want to pull the plug entirely, just delete the key from your .env file (or remove the gorilladesk block from Claude's settings). There's no in-between "read only" mode to fall back to yet, so all-off is the fastest safety net.

For developers

Everything below this point assumes a coding background.

Tool reference

Run the server and call tools/list from any MCP client to see exact input/output schemas; every tool's description includes the HTTP method and path it maps to (e.g. Maps to GET /customers/{customerId}.). Source lives under src/tools/, one file per resource.

Why there's no tier/profile system here (yet)

Every other repo in this series reads a <PLATFORM>_MCP_MODE/<PLATFORM>_MCP_PROFILE pair of environment variables and only registers tools up to the allowed tier (genuinely absent from tools/list, not just hidden). This repo predates that pattern, and given the API surface here is only 9 operations with no delete/void/destructive actions among them, the safety payoff of adding tiers is smaller than on the bigger repos. If GorillaDesk's public API grows, this repo should adopt the same tier system the rest of the series uses. See ROADMAP.md.

Project layout

src/
  index.ts          Server entrypoint (registers every tool group and starts stdio transport)
  client.ts          Minimal fetch-based GorillaDesk API client (auth headers, error handling)
  toolkit.ts          Shared helper that wires a Zod input schema + handler into an MCP tool
  tools/
    company.ts
    users.ts
    customers.ts
    phoneTypes.ts

Notes on the GorillaDesk API

Base URL: https://api.gorilladesk.com/v1
Auth header: Authorization: Bearer <api_key>
Public OpenAPI spec: https://api.gorilladesk.com/v1/specs (YAML, no auth required to fetch)
Rate limits apply per endpoint group; a 429 response includes x-rate-limit-reset

This server was built by reading GorillaDesk's own published OpenAPI spec directly, not by guessing or by reverse-engineering another project. If GorillaDesk publishes more endpoints, open an issue or PR and we'll extend this server to match.

What's next

This is one of a planned series of MCP servers, one per major pest control CRM/FSM used in the US and UK. See ROADMAP.md for the rest of the series, what's next for this repo, and the tiered safety system the bigger repos already have.

Built by BackCrew

This repo is free, open source, and meant to be genuinely useful on its own: clone it, read it, run it, fork it for your own stack.

It's also a demo of the kind of work BackCrew does: we build integrations, automations, and AI tooling for pest control and field service businesses. If you'd rather not stand this up and maintain it yourself (or you want it extended the moment GorillaDesk expands their API, wired into your own internal systems, or built for another CRM entirely), that's a done-for-you engagement we take on.

Want this done for you? Reach out: jayson@backcrew.co

No pressure either way: the code above works standalone.

License

MIT

Available Tools

8 tools

add_customer_noteB

Add a note to a customer's timeline, optionally notifying specific users. Maps to POST /customers/{customerId}/notes.

ParametersJSON Schema

Name	Required	Description
`content`	Yes
`customer_id`	Yes
`notify_user_ids`	No	User IDs to notify about this note

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states the basic function (add note, notify users) but does not reveal whether the note appends or replaces, notification guarantees, rate limits, or any destructive implications. The description is minimal.

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

Conciseness5/5

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

Two concise sentences. The first covers the primary purpose and optional behavior; the second provides the API mapping. No redundant information.

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

Completeness3/5

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

Given no output schema and low schema coverage, the description should provide more context. It lacks details on return values, error handling, and prerequisite conditions. However, the tool is relatively simple, so the description meets a minimum viable level.

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

Parameters2/5

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

Schema coverage is low (33%): only 'notify_user_ids' has a description. The description mentions optional notification, which corresponds to that parameter, but it does not clarify the format of 'content' or the source of 'customer_id'. No additional parameter semantics are provided beyond 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?

The description explicitly states the action (add a note), the resource (customer timeline), and maps to the REST endpoint. It clearly distinguishes from sibling tools which handle companies, users, and customer CRUD, not notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies the tool is for adding a note and optionally notifying users, but it does not provide explicit guidance on when to use it over possible alternatives. There is no mention of prerequisites or conditions for using this tool.

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

create_customerC

Create a new customer with a service location. Maps to POST /customers.

ParametersJSON Schema

Name	Required	Description
`email`	No
`phones`	No
`status`	No
`company`	No
`location`	Yes
`last_name`	No
`first_name`	Yes
`account_number`	No	Must end with a number

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the action and HTTP mapping. It does not disclose whether permissions are required, what side effects occur (e.g., creation of related records), or the response format. Critical behavioral traits are missing.

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 description is only two sentences with no fluff, but it is under-informative for a tool with 8 parameters and nested objects. It could be more structured (e.g., listing prerequisites or output) without becoming verbose.

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

Completeness2/5

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

Given the tool's complexity (8 parameters, nested objects, no output schema), the description is incomplete. It omits what the tool returns, validation rules, and any distinctions from sibling tools beyond the action.

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

Parameters2/5

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

Schema description coverage is only 13%, yet the description adds negligible parameter-level meaning beyond noting that location is part of the creation. For the 8 parameters, only location is hinted at; no details on required fields, email, phones, status, etc., are provided.

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?

The description clearly states the action (Create), the resource (customer), and includes a specific detail (with a service location) that distinguishes it from update/delete operations. The explicit mapping to POST /customers further clarifies the API endpoint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like update_customer or add_customer_note. It does not mention prerequisites, such as needing a valid location or that this tool is for new customers only.

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

get_companyA

Get the connected company's business info: name, contact details, address, timezone, and office hours. Maps to GET /company.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only states that the tool retrieves info and maps to GET /company, lacking details about side effects, permissions, rate limits, or response structure. This is insufficient for an agent to understand the tool's full behavior.

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

Conciseness5/5

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

The description is a single sentence that is concise and front-loaded. Every word serves a purpose, and there is no unnecessary verbosity.

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

Completeness3/5

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

Given no parameters and no output schema, the description is fairly complete for a simple read operation. However, it could be improved by specifying the response format (e.g., single object or list) or any potential constraints (e.g., connected company must be authenticated).

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 input schema has no parameters. With 0 parameters, the baseline is 4. The description adds value by listing the fields returned, but since there are no parameters, there is no additional parameter meaning needed.

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?

The description clearly states the tool retrieves business info for the connected company and lists specific fields (name, contact details, address, timezone, office hours). It also includes the HTTP method mapping, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus sibling tools like list_users or get_user. The description does not mention any alternatives or exclusions, leaving the agent to infer usage context.

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

get_userA

Get a single user's profile: name, role, license, contact info. Maps to GET /users/{userId}.

ParametersJSON Schema

Name	Required	Description	Default
`user_id`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses the return fields and HTTP method, indicating a read operation. However, it omits details like authentication requirements, error conditions, or rate limits. The return value info adds value beyond the schema.

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

Conciseness5/5

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

The description is a single sentence that efficiently conveys purpose and endpoint, with no redundant information. It is front-loaded and every word serves a purpose.

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?

Given the simple nature of the tool (single required parameter, no output schema), the description adequately covers purpose, return fields, and endpoint. It lacks guidance on potential error scenarios or when to use vs siblings, but overall is sufficient for basic usage.

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

Parameters2/5

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

The schema has one required parameter (user_id) with no description, and the tool description does not add any semantic meaning about the parameter (e.g., format, allowed values, or usage context). Since schema coverage is 0%, the description fails to compensate, leaving the parameter under-specified.

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?

The description clearly states it retrieves a single user's profile with specific fields (name, role, license, contact info) and maps to a REST endpoint. This distinguishes it from sibling tools like list_users (multiple users) and get_company (different entity).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies use when needing a single user's details but lacks explicit guidance on when to choose this over list_users or when to avoid it. No alternatives or exclusions are mentioned.

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

list_customersA

List customers with optional filtering, sorting and pagination. Maps to GET /customers.

ParametersJSON Schema

Name	Required	Description
`sort`	No	Prefix a field with - for descending order
`limit`	No	Default 20
`state`	No	Record state, distinct from business status
`offset`	No
`status`	No
`include`	No
`created_after`	No	ISO 8601 timestamp — maps to created[gt]
`updated_after`	No	ISO 8601 timestamp — maps to updated[gt]
`account_number`	No
`created_before`	No	ISO 8601 timestamp — maps to created[lt]
`updated_before`	No	ISO 8601 timestamp — maps to updated[lt]

TDQS

A3.6/5.0

Behavior3/5

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

The description notes that the tool maps to an HTTP GET, implying read-only and idempotent behavior. However, with no annotations provided, it does not clarify other behavioral traits such as scope (all customers? per context?), rate limits, or side effects. The GET mapping provides a baseline level of transparency.

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

Conciseness5/5

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

The description is two sentences long with no redundant or extraneous information. Every word serves a purpose: the verb, resource, core capabilities, and endpoint mapping are clearly and efficiently communicated.

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

Completeness2/5

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

Despite 11 parameters and no output schema or annotations, the description omits important details such as pagination behavior, default order, response structure, error handling, and when to use this over sibling tools (e.g., list_users). The brevity leaves significant gaps for an agent to safely invoke the tool correctly.

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?

The description provides a high-level overview of filtering, sorting, and pagination, but the input schema already covers 64% of parameters with descriptions. The description does not add meaning for undocumented parameters (e.g., include, account_number, status) beyond the schema's baseline. It does not fully compensate for the remaining 36% coverage gap.

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?

The description uses the specific verb 'List' with 'customers' as the resource, directly indicating the tool's function. It adds optional capabilities (filtering, sorting, pagination) and explicitly maps to the REST endpoint 'GET /customers', distinguishing it from sibling tools like create_customer or update_customer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage for listing customers with controls, but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_user for a single customer). No exclusions or prerequisites are mentioned, leaving the agent to infer based on the tool name and siblings.

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

list_phone_typesB

List the phone type labels (e.g. Mobile, Home, Work) available for customer phone numbers. Maps to GET /phone-types.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Default 20
`offset`	No

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It only states 'List' and maps to a GET endpoint, implying read-only, but fails to disclose any potential side effects, authentication needs, rate limits, or behavior when no records exist.

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?

The description is a single, front-loaded sentence with an endpoint reference, containing no extraneous text. However, it could be slightly more informative while still being concise.

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

Completeness3/5

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

For a simple list tool with two optional parameters and no output schema, the description minimally covers the operation. It lacks details on return format, pagination behavior, or ordering, leaving some gaps for an agent.

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 50% (only 'limit' has a description in schema). The tool description adds no additional parameter explanation beyond what the schema already provides, and does not compensate for the missing 'offset' description.

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?

The description clearly states the tool lists phone type labels with examples, and explicitly maps to a GET endpoint, making the purpose unambiguous and distinct from unrelated sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives. The purpose is implied (listing phone types), but no context is given for when one might need this list or any prerequisites.

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

list_usersB

List the company's users (admins and technicians). Maps to GET /users.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Default 20
`offset`	No

TDQS

B3.3/5.0

Behavior3/5

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

No annotations provided, so description must cover behavior. It mentions it's a GET endpoint (read-only), but lacks details on pagination, authentication, or error handling. Adequate but not comprehensive.

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?

Single sentence is concise and includes resource and endpoint. Could be expanded slightly (e.g., mention pagination) without becoming verbose.

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

Completeness3/5

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

For a simple list tool with 2 params and no output schema, description covers purpose but omits output format, pagination semantics, and potential error states. Minimum viable for basic use.

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

Parameters2/5

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

Schema description coverage is 50% (only limit has description); description does not add any parameter meaning. It neither explains offset nor clarifies pagination behavior, leaving gaps that the schema partially fills.

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?

Description clearly states it lists users (admins and technicians) and maps to GET /users. Distinguishes from siblings like get_user (single) and list_customers (customers).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives (e.g., get_user for single user, list_customers for customers). Implied by sibling names but not explicit.

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

update_customerC

Update an existing customer's core details. Maps to PUT /customers/{customerId}.

ParametersJSON Schema

Name	Required	Description
`email`	No
`phones`	No
`status`	No
`company`	No
`last_name`	No
`first_name`	Yes
`customer_id`	Yes
`account_number`	No	Must end with a number

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only mentions the HTTP method (PUT), which implies idempotence, but doesn't clarify what happens if the customer doesn't exist, whether it's a partial update, or any side effects. No auth or rate limit info.

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 description is extremely brief, only one sentence. While it is front-loaded, it omits critical information. It could be expanded without losing structure.

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

Completeness1/5

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

Given 8 parameters, no output schema, and no annotations, the description is severely incomplete. It lacks guidance on required parameters' meaning, return behavior, and error conditions. This tool requires much more context.

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

Parameters1/5

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

Schema description coverage is only 13%, meaning 7 out of 8 parameters lack description. The tool description adds no parameter information whatsoever, leaving the agent to rely solely on the schema, which is inadequate.

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?

The description clearly states the verb 'Update', the resource 'customer', and specifies it is for existing customers. It also shows the HTTP mapping, which clarifies the operation. This distinguishes it from sibling tools like create_customer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no conditions for usage. It is implied only by the tool name and verb.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.1.0Jul 24, 2026
- First observedadd_customer_note
- First observedcreate_customer
- First observedget_company
- First observedget_user
- First observedlist_customers
- First observedlist_phone_types
- First observedlist_users
- First observedupdate_customer

Deploy Server

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

TDQS

B3.4/5.0

Scored 2026-09-09 18:05 across 8 tools

Disambiguation5/5

Each tool targets a distinct resource and action: company info, user collection vs single user, customer collection vs create/update, customer notes, and phone type lookup. There is no meaningful overlap or ambiguity between tool purposes.

Naming Consistency5/5

All tool names follow a consistent lower_snake_case verb_noun pattern, such as list_users, get_user, create_customer, and add_customer_note. The naming clearly signals both the action and the resource, making the set predictable.

Tool Count5/5

Eight tools is a well-scoped size for this server's apparent focus on company, user, and customer data. Each tool has a clear purpose and none feel redundant or unnecessary.

Completeness3/5

The customer workflow has create, list, and update support but lacks a dedicated get-by-id and delete operation, leaving the customer lifecycle incomplete. Note management is also add-only, and users are read-only, so some common management workflows require external workarounds.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

OnlineFitness.appOAuth
app.onlinefitness
Manage fitness coaching clients, workouts, programs, chats and funnels from your assistant.
Health & Wellness Fitness Tracking
1
PlixanaOAuth
com.plixana
Operate the Plixana CRM from any AI: contacts, deals, quotes, WhatsApp and metrics.
CRM Communication
2
Famulor BOAuth
io.famulor
Manage AI assistants, history, calls, campaigns, contacts, knowledge, messaging, and automations.
Speech Processing Communication Knowledge & Memory
21
EasyWeek BusinessOAuth
io.easyweek
Manage an EasyWeek business from AI: bookings, availability, customers, services, orders, messaging.
Calendar Management CRM
1

Related MCP Servers

Gorgias MCP Server
Customer Support Communication
mattcoatsworth
F
license
Not graded
quality
D
maintenance
Enables interaction with the Gorgias helpdesk API, providing tools to manage tickets, customers, and other helpdesk functionalities through natural language.
Updated a year ago (2025-03-31 13:13 UTC)
4
-
gorgias-mcp
Customer Support E-commerce & Retail
NoBanks
A
license
Not graded
quality
D
maintenance
Enables AI agents to manage Gorgias support tickets: list open tickets, read conversation history, draft internal notes, send outbound replies (gated), and look up customer history.
Updated 4 months ago (2026-05-29 01:23 UTC)
MIT
Twenty CRM MCP Server
CRM Databases
mhenry3164
A
license
Not graded
quality
C
maintenance
Connects Twenty CRM with AI assistants like Claude, enabling natural language interactions with customer data. Supports CRUD operations for people, companies, tasks, notes, and advanced search.
Updated 2 months ago (2026-07-30 19:48 UTC)
11 npm
104
MIT
GHL MCP Server
CRM App Automation
mnewby20305
A
license
Not graded
quality
D
maintenance
Enables Claude to manage GoHighLevel CRM contacts, pipelines, and workflows through natural language commands.
Updated 3 months ago (2026-06-10 16:59 UTC)
36 npm
MIT

BackCrew GorillaDesk MCP Server

Contents

What this actually does

Why use an independent MCP server instead of the platform's own AI?

What this server can't do yet (read this before you get your hopes up)

Also from BackCrew

Some words you'll see, explained

How this keeps you safe

What it can do

How to set it up

Step 1: Make a folder for this on your computer

Step 2: Get your GorillaDesk key

Step 3: Install it

Connecting it to Claude

Claude Desktop / Claude Code

Things you can try asking

Testing it safely

For developers

Tool reference

Why there's no tier/profile system here (yet)

Project layout

Notes on the GorillaDesk API

What's next

Built by BackCrew

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers