Ask GorillaDesk (gorilladesk-mcp)

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
There is overlap between natural-language query tools (e.g., how_much_money, who_owes_me_money) and generic search tools (e.g., search_invoices, search_customers), though descriptions mitigate confusion with 'Prefer' hints. A few pairs like search_customers/find_customer and search_jobs/whats_on_the_schedule are nearly interchangeable and could lead to misselection.
Naming Consistency3/5
The set mixes natural-language question phrases (how_much_money, who_are_my_technicians) with standard verb_noun patterns (search_customers, get_job). Each style is internally consistent, but the lack of a unified naming convention makes it harder to predict tool names across the whole server.
Tool Count4/5
19 tools is slightly over the ideal 3-15 range but appropriate for the breadth of the GorillaDesk domain (customers, jobs, invoices, payments, estimates, services, users). The two-layer design (answer-oriented vs. data-access) adds functionality but also inflates the count.
Completeness4/5
The toolkit covers the core entities needed for a read-only business assistant. Minor gaps exist, such as missing get_* tools for payments, estimates, services, and users, but the search tools likely return sufficient detail for most 'ask' scenarios.
Average 3.7/5 across 19 of 19 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, but the description adds no extra behavioral context such as pagination behavior, default filters, or response shape. It only repeats the generic list/filter concept.
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 concise at only three words, which makes it front-loaded and easy to scan. However, it is under-specified, and the brevity sacrifices necessary detail, so it earns a mid-range score.
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 lack of parameter descriptions and the presence of many sibling tools, the description is incomplete. It does not explain what an estimate is in this domain or what makes this tool different, leaving an agent without sufficient context to invoke it correctly.
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 0%, so the description must compensate, but it only mentions 'filter' without explaining how any parameter (limit, offset, status, customer_id) works. Parameter meanings are left to inference, adding minimal value over the schema.
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 clearly states the tool lists/filters estimates, providing a specific verb and resource. However, it does not distinguish itself from sibling search tools beyond the resource name, so it falls short of a 5.
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 alternatives like search_jobs or search_invoices. It neither provides context nor excludes any scenarios, leaving the agent without explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which cover the safety profile. The description adds no additional behavioral context such as pagination, filtering semantics, or return format, but it does not contradict the annotations.
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 description is extremely short but under-specified. While it is front-loaded, it lacks critical detail needed to use the tool effectively. It is not conciseness but rather an incomplete specification.
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 has five parameters and no parameter descriptions, the description is inadequate. It does not explain what 'filter' means, what date ranges are expected, or how paging works, and it provides no context beyond the bare purpose.
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 0%, and the description does not mention any of the five parameters (limit, offset, start_date, end_date, customer_id). The parameters are left entirely to the schema titles, which provide minimal meaning.
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 'List/filter payments' clearly identifies the verb (list/filter) and resource (payments), distinguishing it from sibling tools like search_invoices and search_jobs. It is specific and 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, exclusions, or prerequisites, leaving the agent without direction on appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description only needs to add extra behavioral context. It adds the searchable fields (name, company, email, account number) but does not disclose return format, limit behavior, or matching semantics. This is acceptable but not rich.
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 short, but the opening 'Answer: ...' is an unusual and slightly confusing formatting choice. The second sentence is clear and concise, but the overall structure is awkward and doesn't follow standard tool-description conventions.
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?
The tool is simple, with good annotations and an output schema, but the description leaves gaps: how query matching works (partial vs exact), what limit controls, and how results are ordered. The existence of sibling tools adds ambiguity about when to choose this one, so more context would improve completeness.
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?
With 0% schema description coverage, the description must compensate. It explains the 'query' parameter by listing the searchable fields, but the 'limit' parameter is left completely undocumented in both the schema and the description. Partial compensation, not full.
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 clearly states the tool searches customers by name, company, email, or account number, with concrete example queries. However, it does not differentiate from the sibling tool 'search_customers', which likely has a very similar purpose.
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 example queries imply usage for finding a customer when you have partial identifying information, but there is no explicit guidance on when to use this tool versus siblings like get_customer or search_customers. The usage context is implied rather than clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnly, idempotent, and non-destructive, so the safety profile is well-covered. The description adds no behavioral context beyond the tool's basic function, such as potential 404s, the effect of the 'include' parameter, or response structure. This is acceptable given the strong annotations, but the description itself does not enhance 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 a single short sentence that conveys the essential purpose without any fluff. It is appropriately front-loaded and every word earns its place. No unnecessary information is included, making it an exemplary model of conciseness.
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?
The tool is simple: one required param and one optional param, with an output schema present and clear annotations. The description, while minimal, covers the fundamental purpose of the tool. The presence of an output schema eliminates the need to describe return values. It does not address the 'include' parameter or edge cases, but for a get-by-id operation, the description is reasonably complete.
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 0%, so the description must compensate for explaining parameters. It only says 'by id', which merely restates the invoice_id property already in the schema. The 'include' parameter is completely unexplained, and no additional meaning is added beyond what the schema already provides. This is a significant gap for a tool with two parameters, especially one optional field.
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 'Fetch one invoice by id' clearly states a specific action (fetch) on a specific resource (invoice) with a precise scope (by id). It distinguishes itself from sibling tools like search_invoices, which lists or searches for invoices, whereas this tool retrieves a single one. The verb+resource+scope construction is unambiguous and high-quality.
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 explicit guidance on when to use this tool versus alternatives. It does not state 'use this when you have an invoice ID' or mention that search_invoices should be used when you don't have an ID. The implied use case (having an ID) is present, but there is no clear context or exclusion, so the tool offers minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent, and the description adds that it returns jobs plus invoiced/collected over a date window. However, it doesn't disclose return format, pagination, or how the aggregation is computed. This is consistent with annotations, so no contradiction.
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 very short, front-loads the user-facing trigger phrases, and then specifies the data scope. The 'Answer:' prefix and quotes are slightly awkward but add no real waste.
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?
The tool is simple, has optional parameters, and an output schema exists, but the description leaves ambiguity about start/end date semantics and how the default window is applied. It is adequate for a basic snapshot tool but has clear gaps.
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 0% parameter description coverage, and the description only says 'date window (default 30 days),' which partially covers the `days` parameter. It does not explain how `start_date` and `end_date` interact with `days`, their format, or precedence, leaving most parameters under-documented.
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 identifies the tool as answering 'How's business?' and providing a snapshot of 'Jobs + invoiced/collected for a date window,' which names a specific resource and scope. It doesn't explicitly contrast with sibling tools like how_much_money or who_owes_me_money, but the intent is clear.
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?
The description gives explicit trigger phrases ('How's business?', 'Give me a snapshot') and states the default date window (30 days), giving clear context for when to use it. It doesn't mention when not to use it or name alternatives, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds no additional behavioral context beyond 'List/filter', which is already implied by the name and annotations, so it neither contradicts nor enriches.
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 short sentences with no fluff. The first sentence states purpose, the second gives a targeted usage hint. Every word earns its place.
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 having an output schema and safe annotations, the description is too sparse for a search tool with 6 optional parameters. It doesn't explain how parameters relate to filtering behavior, nor does it differentiate from get_job for retrieving a single job. The guidance about 'whats_on_the_schedule' helps but leaves many usage questions unanswered.
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?
With 0% schema description coverage, the description must compensate by explaining parameters, but it only says 'List/filter jobs'. The parameter names (limit, offset, keyword, dates, customer_id) are somewhat self-explanatory, but ambiguous aspects like what fields 'keyword' searches or date formats are not clarified.
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 'List/filter jobs' clearly states the verb and resource, making the tool's purpose obvious. It also distinguishes from siblings by directing users to 'whats_on_the_schedule' for owner questions, though it doesn't explicitly define scope limitations beyond that.
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?
The instruction 'Prefer whats_on_the_schedule for owner questions' provides an explicit alternative for a specific use case, offering some when-not guidance. However, it doesn't mention other sibling tools like get_job or search_customers, so guidance is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the listing/filtering behavior but does not disclose pagination limits, filter semantics, or output structure. It provides some value beyond annotations but lacks rich behavioral detail.
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 short sentences, perfectly front-loaded with the main purpose and then a focused usage note. Every word earns its place, with zero redundancy or explanation of obvious facts.
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?
With four optional parameters, no parameter documentation, and no description of the response format (despite an output schema existing), the description leaves significant gaps. The agent must guess what status and account_number mean and how limit/offset behave. The owner-questions distinction is mentioned but not clarified.
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 0%, with no parameter descriptions in the schema. The description includes no mention of limit, offset, status, or account_number, leaving their meaning and purpose entirely unclear. This gives no help to an agent in constructing a correct call.
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 opens with 'List/filter customers', which clearly states the verb and resource. It also explicitly distinguishes the tool from siblings by noting that find_customer / how_many_customers should be preferred for owner questions, giving immediate differentiation.
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?
The second sentence provides explicit guidance: 'Prefer find_customer / how_many_customers for owner questions.' This tells the agent when to use alternatives, though it does not fully elaborate on all use cases or exclusions. The context is clear enough for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral context like rate limits, authentication, or edge cases, staying minimal. It aligns with annotations without contradiction.
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, front-loaded sentence with no redundant words. Every word earns its place, making it optimally concise for an AI agent to parse quickly.
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 simplicity of the tool, an output schema that clarifies return values, and comprehensive annotations, the description is adequate for basic retrieval. However, the unexplained 'include' parameter prevents a perfect score, as users/agents won't know how to utilize it without further info.
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 0%, so the description carries the burden for parameter meaning. It only mentions 'id' for job_id, which is already evident from the schema, and entirely omits the 'include' parameter. This leaves a significant semantic gap for the optional parameter.
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 'Fetch' and the resource 'one job' with the key identifier 'by id'. This differentiates it from siblings like search_jobs, which imply broader querying.
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 when you have a specific job id, but it does not explicitly contrast with search_jobs or provide when-not-to-use guidance. The distinction is implicit from the tool name and wording rather than explicit in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, which cover the safety profile. The description 'List/filter invoices' does not add behavioral context beyond that, such as pagination behavior, sorting, or response format. Since annotations handle the safety dimensions, a 3 is appropriate for this neutral but non-contradictory addition.
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 short sentences with no redundant wording. The first sentence delivers the core purpose, and the second provides a targeted usage hint. Every word earns its place.
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 having an output schema (which reduces the need to describe return values), the description remains extremely thin. It does not outline available filters, pagination semantics, or any use case nuance beyond the owner preference. For a tool with 6 optional parameters and no parameter documentation, this level of detail is insufficient for an agent to select and invoke it with confidence in varied scenarios.
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 input schema has 0% description coverage for its 6 parameters, and the description does not mention any parameter details or meanings. The agent is left to infer semantics from names like status, start_date, and customer_id, which may be insufficient for correct invocation. The description fails to compensate for the schema's lack of documentation.
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's function with the verb 'List/filter' and specifies the resource 'invoices'. It also distinguishes from siblings by explicitly naming who_owes_me_money and how_much_money for owner-specific queries, making the scope precise.
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?
The description gives explicit guidance to prefer who_owes_me_money or how_much_money for owners, which helps an agent choose an alternative. However, it does not enumerate other potential alternatives (e.g., get_invoice, search_payments) or provide deep context on when search_invoices is the right choice beyond the general list/filter role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the description's burden is lower. It adds the useful context that it reports both invoiced and collected totals and defaults to a 30-day window, but it leaves ambiguity about which date field the window applies to and whether the totals are returned separately or combined.
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 extremely compact: two sentences deliver example queries and the core output definition with no redundant wording. The front-loaded examples immediately orient the agent.
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?
The tool is simple and has an output schema plus strong annotations, so the description doesn't need to detail return values. However, the incomplete parameter semantics and the ambiguity about 'collected' (payments received, cash basis, etc.) prevent it from being a fully complete guidance.
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 0%, but the description only mentions a 'date window (default 30 days),' which maps loosely to the days parameter. It does not explain the format or role of start_date and end_date, nor how they interact with days, leaving the three parameters 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 opens with example user questions that clearly identify the tool's purpose, then states 'Invoiced + collected totals for a date window,' which is a specific verb+resource statement. It is easily distinguished from siblings like who_owes_me_money because it targets gross invoicing and collections rather than outstanding balances.
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?
The example questions provide clear guidance on when an agent should invoke this tool (e.g., 'How much money came in?', 'What did we invoice this month?'), and the date-window note indicates the temporal scoping. It does not explicitly call out alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a scoping note (not for owner questions) but does not describe pagination behavior or response details beyond the output 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?
Two sentences, the first being a concise purpose statement. No redundant information; every word earns its place.
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 the existence of an output schema, return values are covered. However, the description does not address the 'search' vs 'list' distinction implied by the tool name, nor does it explain pagination behavior. It's adequate for a basic list but lacks 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?
The input schema provides only names and defaults for limit and offset, with no descriptions. The description does not mention these parameters at all, failing to clarify their purpose beyond the self-explanatory names.
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 states 'List users' which clearly defines the action and resource. The additional sentence 'Prefer who_are_my_technicians for owner questions' differentiates it from the sibling tool, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to prefer 'who_are_my_technicians' for owner questions, providing an alternative and context. This is a clear usage guideline that helps the agent choose between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so safety is clear. The description adds only the 'Lists' behavior, which overlaps with purpose; no additional behavioral context beyond annotations.
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?
Extremely concise: two sentences, front-loaded with trigger questions, no filler. Every word adds value.
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 simple, parameterless List operation with an output schema already defined, the description is complete. It clearly states what the tool does and when to use it, and the existing schema and annotations handle the rest.
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 has 0 parameters, and schema coverage is 100%, so baseline is 4. The description doesn't need to explain parameters; the empty schema suffices.
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 clearly states it Lists GorillaDesk services and provides natural-language triggers. It distinguishes from search_services by implying a full catalog listing, though it doesn't explicitly say 'all' services.
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?
Provides example questions that indicate when to use the tool, but gives no exclusions or alternatives. No mention of search_services for more targeted service queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds that the tool covers a date range with a default of 7 days, but it does not disclose return format or how date parameters interact.
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 concise, consisting of two sentences with no superfluous content. It front-loads example questions and then states the core functionality, with every sentence earning its place.
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 simple read-only tool with rich annotations and an output schema, the description covers the main purpose and usage context. However, the ambiguity around parameter interactions prevents it from being fully complete.
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 0%, and the description only mentions a default of 7 days, which relates to the 'days' parameter. It does not explain 'start_date' or 'end_date', or how they interact with 'days', leaving the agent without critical parameter semantics.
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 provides a jobs overview for a date range, with example questions it answers ('What's on the schedule?', 'How many jobs this week?'). This distinguishes it from sibling tools like search_jobs by focusing on a schedule overview with a default 7-day period.
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?
The description includes example queries that give clear usage context ('What's on the schedule?', 'How many jobs this week?'), indicating when to use the tool. However, it does not explicitly mention alternatives or when not to use it, so it lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds minimal behavioral context ('prefer find_customer first'), but does not disclose anything about missing IDs, response format, or the 'include' parameter. It is adequate but not rich.
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 short sentences with no filler. Efficiently communicates purpose and usage priority in minimal words.
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?
With an output schema and strong annotations, the description is sufficient for the basic fetch functionality, but the 'include' parameter remains unexplained and there is no guidance on edge cases. The usage note about find_customer adds context, but the tool description leaves some gaps around parameter behavior.
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 0%, and the description only mentions 'by id' (mapping to customer_id) without explaining the 'include' parameter. The schema provides types/defaults but not semantic meaning, and the description fails to compensate for the missing entirely undocumented parameter.
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 'Fetch one customer by id' – a specific verb and resource. It distinguishes from sibling tools like find_customer and search_customers by specifying a direct ID-based fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Prefer find_customer first,' providing a direct alternative and indicating when to use this tool as a fallback. This is clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral details beyond 'List services,' such as pagination or ordering behavior. It does not contradict the annotations.
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 short sentences with no filler. The first states the action, and the second provides a crucial usage alternative. Every word earns its place.
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 simple list tool with an output schema and clear sibling guidance, the description covers the core purpose and usage. The main gap is parameter semantics, but the overall context is sufficiently complete for a tool of this complexity.
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 0% description coverage, and the description does not mention the limit or offset parameters. Although these are common pagination names, the description provides no guidance on their meaning or defaults, leaving the agent to infer.
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 'List services' clearly states the action and resource. It further distinguishes this tool from its sibling 'what_services_do_we_offer' by directing owner questions to the alternative, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Prefer what_services_do_we_offer for owner questions,' giving a clear when-not-to-use instruction with a named alternative. This is strong usage guidance even though it doesn't enumerate all possible scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds the specific behavioral context that the tool filters for open invoices and ranks them by amount due, which is not evident from annotations or schema. It does not mention output format details, but the output schema covers that.
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 extremely concise at two sentences, with the first sentence providing example queries and the second stating the core operation. No redundant information, and the most important behavioral detail is front-loaded.
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 simple read-only query tool with an output schema, the description provides the essential function and usage examples. It could improve by explicitly mentioning how top_n affects results, but the overall picture is sufficiently complete for an agent to invoke the tool correctly.
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 0% description coverage for the single parameter top_n, and the description does not mention or explain it. The parameter name is somewhat self-explanatory and has a default, but the description fails to add any meaning 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 clearly states the tool's function with a specific verb 'ranks' and a resource 'open GorillaDesk invoices', and even provides example natural-language queries. This distinguishes it from sibling tools like search_invoices, which likely list invoices without ranking by amount due.
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?
The description embeds usage triggers by giving example questions ('Who owes me money?', 'What's my AR?', 'Who has open invoices?'), telling the agent when to select this tool. However, it does not explicitly contrast it with alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's safety profile is covered. It adds that the tool returns users with roles, but doesn't disclose details like pagination or active/inactive status. This is acceptable for a simple list tool with no parameters.
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 extremely concise, with two short sentences that directly state the tool's purpose and example queries. Every word adds value, and the most important information is front-loaded.
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?
Given the tool's simplicity (0 params), rich annotations (readOnly, idempotent, non-destructive), and existing output schema, the description is fully sufficient. It clearly communicates what the tool does and when to use it.
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?
There are zero parameters, so the description doesn't need to explain parameter meanings. The baseline for 0-parameter tools is 4, and the description correctly implies no input is required.
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 GorillaDesk users with roles, which is a specific verb+resource combination. The example questions help distinguish it from other user-related tools like search_users by focusing on technicians/team.
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?
The description provides clear trigger phrases ("Who are my technicians?", "Who's on my team?"), indicating when the tool should be used. While it doesn't explicitly exclude alternatives, the context is unambiguous enough for an agent to select this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by specifying the exact endpoint called (GET /v1/company) and the success outcome (returns a small company summary), which goes beyond annotation-only disclosure.
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 short sentences, front-loaded with the purpose and a usage directive. Every sentence earns its place: the first states what it does, the second explains the implementation and outcome. No wasted words.
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 zero-parameter health check with an output schema present, the description is complete. It explains the purpose, when to use it, the underlying call, and the success result. There are no missing critical aspects like return format or failure modes, especially given the simplicity and existing schema.
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 has zero parameters, and schema coverage is 100% (empty schema). The baseline for zero params is 4, and the description needs no parameter explanations. It implicitly confirms no inputs are required by describing the call as a direct GET without inputs.
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 states a specific verb and resource: 'Verify GorillaDesk credentials.' It clearly distinguishes itself from sibling business-query tools by focusing on operational health, not domain data. The mention of the API endpoint (GET /v1/company) further clarifies its role.
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?
The description gives an explicit trigger: 'Run this first if other tools fail.' This is clear when-to-use guidance, though it does not explicitly name alternatives or exclude scenarios. The context of being a first-line diagnostic is well conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is clear. The description adds useful behavioral info: it counts only active customers and provides a status breakdown, which is not obvious from the tool name alone. This adds value beyond the annotations.
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 extremely concise: two sentences, front-loaded with example questions, and immediately states the core behavior. Every word earns its place with no fluff or repetition.
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 zero-parameter aggregation tool with an output schema present, the description is fully sufficient. It covers the what (count of active customers), the how (breakdown by status), and implies the result format. Nothing important is missing given the tool's simplicity.
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 has zero parameters, which gives a baseline of 4. The description does not need to explain any parameters since there are none; the schema is already complete at 100% coverage. No additional semantic explanation is required.
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 a specific verb ('Counts') and names the resource ('active GorillaDesk customers') plus the breakdown by status. It clearly distinguishes itself from sibling tools like search_customers or get_customer, which list or retrieve individual records rather than an aggregate count.
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?
The description implies when to use this tool: when a user asks for a customer count or total, not for individual customer details. It provides clear context but does not explicitly mention alternative tools or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![gorilladesk-mcp MCP server](https://glama.ai/mcp/servers/daisydaines/gorilladesk-mcp/badges/card.svg)](https://glama.ai/mcp/servers/daisydaines/gorilladesk-mcp)

Score Badge

Copy to your README.md:

[![gorilladesk-mcp MCP server](https://glama.ai/mcp/servers/daisydaines/gorilladesk-mcp/badges/score.svg)](https://glama.ai/mcp/servers/daisydaines/gorilladesk-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/daisydaines/gorilladesk-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server