BackCrew Jobber MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource (clients, account, jobs, invoices, quotes, properties, users) with either list or get operations. There is no ambiguity between tools.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (e.g., list_clients, get_job, get_invoice). No deviations or mixed conventions.
Tool Count5/5
With 12 tools, the set is well-scoped for a read-only server focused on core entities of a field service management platform. Not too many, not too few.
Completeness4/5
The tools cover read operations for all major entities (clients, jobs, invoices, quotes, properties, users). Missing write operations and potentially entities like visits, but the read-only scope is clearly stated and consistently implemented.
Average 3.8/5 across 12 of 12 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 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?
Without annotations, the description carries the full burden. It discloses Relay pagination and a [tier: readonly-owner] hint, but lacks details on default behavior, ordering, response structure, or side effects. The minimal transparency is insufficient for a tool with no 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?
Three concise pieces of information, each earning its place: purpose, pagination style, and underlying query. No wasted words and front-loaded with the main action.
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?
For a list tool with 3 parameters, no output schema, and no annotations, the description is too brief. It lacks details on what is returned by default, how pagination works concretely (e.g., cursor format), and error handling. The [tier: readonly-owner] hint is vague.
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 description does not explain any parameters beyond what the schema provides. Schema coverage is 67% (two of three parameters have descriptions), but the description adds no extra meaning for 'after' or 'first' in the context of Relay pagination. The pagination mention is implicit and does not directly link to parameters.
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 'List jobs' with a specific verb and resource, and adds that it is Relay-paginated and maps to a GraphQL query. This sufficiently differentiates it from sibling tools like get_job (single job) and list_clients (different resource).
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 versus alternatives. It does not mention when not to use it, nor does it provide prerequisites or filtering options. The description only implies a general listing use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry full behavioral disclosure. It mentions a tier 'readonly-owner', hinting at read-only access and ownership requirements, but lacks details on side effects, rate limits, or response 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 extremely concise with one sentence and two tags, no wasted words. It front-loads the core action and includes relevant context (GraphQL mapping and permission tier). Every element 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 no output schema, the description does not explain what fields are returned or provide any completeness about the response. It is minimally adequate for a simple retrieval tool but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters ('id' and 'fields') already present. The tool description adds no extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.
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 a single invoice by ID. It uses a specific verb 'Get' and resource 'single invoice', distinguishing it from siblings like list_invoices which lists multiple invoices.
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 such as list_invoices or other getters. It only states what it does without exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only provides a tier tag ('readonly-owner') without explaining its meaning. It does not disclose side effects, authentication requirements, or response behavior beyond being a query.
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 sentences and a tag, containing no waste. It efficiently communicates the core purpose.
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 read tool with full schema coverage, the description adequately states intent but lacks usage guidance and deeper behavioral context. It is minimally complete but could improve with more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema describes both parameters. The description adds no new semantics beyond the schema, though the GraphQL mapping provides marginal context for the 'fields' 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 'Get' and resource 'single property by ID', distinguishing it from sibling tools like list_properties that fetch multiple properties. It also provides context by mapping to a GraphQL query.
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 property ID, but does not explicitly state when to use this tool over siblings or when not to use it. No alternative or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions Relay-pagination and readonly-owner, but omits important details like whether it is read-only, rate limits, or what the cursor type is. The description is insufficient for this dimension.
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: one sentence plus a bracketed tag. It is front-loaded with the core purpose, and every part adds value. No 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?
Given the tool has 3 params and no output schema, the description is somewhat incomplete. It mentions pagination and tier, but does not explain cursor usage, ordering, or what fields default includes. The agent can partially infer from sibling tools, but gaps remain.
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 67% (2 of 3 params have descriptions). The description adds no parameter-specific information beyond what the schema provides. The 'Relay-paginated' term loosely relates to 'after' and 'first', but does not add syntax or format details, so baseline 3 is appropriate.
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 'List invoices' with specific verb and resource. It adds context: Relay-paginated, maps to GraphQL query, and readonly-owner tier, which distinguishes it from sibling tools like list_clients or get_invoice.
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 does not explicitly state when to use this tool versus alternatives like get_invoice. The 'Relay-paginated' hint and readonly-owner tier imply some context, but lack explicit when-to-use or when-not-to-use 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?
No annotations are present, so the description carries the burden. It discloses the tool is readonly (via tier tag) and maps to a GraphQL query, which implies safety and structure. However, it does not describe behavior on invalid IDs, error handling, or any side effects. It provides some context but not comprehensive 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 extremely concise: one sentence plus a tag. Every element serves a purpose: what it does ('Get a single quote by ID'), technical backing ('Maps to the GraphQL `quote` query'), and permissions context ('[tier: readonly-owner]'). No redundant words.
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 tool's simplicity (2 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, technical detail, and permission model. Missing are behaviors on missing IDs or pagination, but for a single-resource retrieval tool, these are minor gaps. The sibling tools help contextualize its role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described. The description adds minimal value beyond the schema, only mentioning the GraphQL query mapping which indirectly informs the 'fields' parameter. Baseline 3 is appropriate as the description does not significantly enhance parameter understanding.
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 gets a single quote by ID, using a specific verb and resource. It distinguishes itself from the sibling 'list_quotes' tool by focusing on a single entity retrieval, and the mention of the GraphQL `quote` query adds specificity.
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 quote ID, but it does not explicitly state when to use this tool versus alternatives like 'list_quotes'. No exclusions or prerequisites are mentioned. The context from sibling tools provides implicit guidance, but the description itself lacks direct usage instructions.
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?
With no annotations, the description carries the full burden. It discloses pagination behavior ('Relay-paginated') and a readonly tier hint, but lacks details on idempotency, rate limits, or data consistency. It adds some value but leaves gaps.
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 with a tag, using no unnecessary words. Every element earns its place, providing clear and efficient information.
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 three parameters, the description is mostly complete. It covers pagination and the underlying query. However, it misses details on output structure (e.g., Relay connection format) and ordering. Still adequate given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the GraphQL query mapping and a safety valve note for the 'fields' parameter, but these are partially redundant with the schema description. No significant extra meaning beyond 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 'List clients (customers)' with a specific verb and resource. It differentiates from sibling 'get_client' by indicating a list operation. The mention of Relay pagination and GraphQL query mapping adds clarity.
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 does not explicitly state when to use this tool versus alternatives like 'get_client' or other list tools. Usage is implied from the name and pagination mention, but no exclusions or context cues are provided.
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?
With no annotations, the description adds the 'readonly-owner' tier hint, disclosing the operation's read-only nature and required permissions. It also notes the underlying GraphQL query, providing some behavioral context.
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, using only two sentences plus a tag. It is front-loaded with the core purpose and contains no unnecessary 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?
The description lacks details about the return structure or error cases, and there is no output schema. However, it does mention the default fields and that the 'fields' parameter can override them, offering some 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?
Schema coverage is 100%, so the baseline is 3. The description does not add extra meaning to the parameters beyond what the schema already provides, though it does link the tool to a GraphQL query.
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 a single job by ID, using a specific verb and resource. It is distinct from sibling tool 'list_jobs' which retrieves multiple jobs.
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 compare with alternatives like 'list_jobs' or specify when not to use this tool.
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?
With no annotations provided, the description carries full burden. It adds behavioral context with '[tier: readonly-owner]', indicating read-only access and owner-level permissions, which helps agents understand safety and authorization. No further details on side effects or rate limits, but the tier information is valuable.
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, no redundant information, and front-loaded key purpose. Every word adds value.
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 retrieval tool with two well-documented parameters and no output schema, the description covers the main purpose and behavioral tier. It could optionally mention default fields or error handling, but it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description does not add further meaning beyond what is in the schema, such as clarifying the 'fields' parameter usage or format. Baseline score of 3 is appropriate.
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 a single client by ID, with verb 'Get' and specific resource 'client'. It distinguishes from sibling tools like 'list_clients' (which retrieves multiple clients) and other 'get_*' tools. The mention of the GraphQL 'client' query adds clarity.
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 for single client retrieval by ID but does not explicitly state when or when not to use it. No mention of alternatives like 'list_clients' or conditions for skipping this tool.
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?
Description adds meaningful behavioral context: Relay pagination, readonly tier, GraphQL mapping. Lacks details on error handling or auth specifics but sufficient for a simple read operation.
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 conveying purpose, pagination, mapping, and permissions. No wasted words.
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?
Covers key aspects: resource, pagination, readonly. No output schema needed? Would benefit from mention of return format or default field set, but adequate for a simple list tool.
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?
Description does not explain parameters beyond hinting pagination via 'Relay-paginated'. Schema covers two of three parameters with descriptions; no added value from description. Baseline 3.
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 (list) and resource (users/team members), and distinguishes from siblings like list_clients. It also provides implementation details (Relay-paginated, GraphQL mapping).
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 when-to-use or when-not-to-use guidance. Purpose is clear from resource name, but alternatives or exclusions are not mentioned. Minimal 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?
No annotations are provided, so the description must carry the burden. It mentions the tool is 'readonly-owner' and maps to a GraphQL query, implying a safe read operation. However, it does not explicitly state idempotency, side effects, or auth requirements beyond the tier tag.
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 and a tier tag. Every word is meaningful, no fluff. It is front-loaded with the primary purpose.
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 get operation with one optional parameter and no output schema, the description is complete. It covers the purpose, GraphQL mapping, and permission tier. No additional context is needed for effective use.
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 only parameter, 'fields', is described in both the schema and the tool description. The schema coverage is 100%, so the description adds no extra meaning beyond what the schema already provides. Baseline 3 applies.
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 'Get the connected Jobber account's basic info', specifying the verb ('Get'), resource ('account'), and scope ('basic info'). It distinguishes itself from sibling tools like get_client or list_jobs by focusing on the account entity.
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 context (read-only owner tier, GraphQL mapping), but does not explicitly state when to use this tool vs alternatives. However, since siblings target different entities, the usage is implicitly clear.
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?
With no annotations, the description adds value by including a '[tier: readonly-owner]' tag indicating read-only behavior and access level. It also discloses the Relay-based pagination style. However, it does not mention authentication requirements or potential side effects, though the readonly hint mitigates this.
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, each adding distinct value: first states purpose and pagination, second maps to GraphQL and adds a security tier. No redundant information.
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 no output schema and moderate complexity (3 params), the description covers purpose, pagination style, and a security tier. It lacks details on the return format or error conditions, but the list operation's output is implicitly properties. Mostly complete for a paginated list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%; the description compensates for the undocumented 'after' parameter by implying it's a cursor from Relay pagination. It also adds context to 'fields' as a GraphQL selection set. The description adds meaning beyond the schema, especially for the cursor 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 'list' and resource 'service properties (addresses)', includes pagination method 'Relay-paginated', and implicitly distinguishes from sibling tools like 'get_property' (single resource) by specifying it's a list operation.
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 mentions it's a paginated list mapping to a GraphQL query, but lacks explicit guidance on when to use this tool versus alternatives like 'get_property' for single properties or 'list_clients' for different resources. Usage context is implied but not directly stated.
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?
No annotations provided, so description fully discloses behavior. States it's read-only (owner), Relay-paginated, and maps to specific GraphQL query. Lacks details like default ordering or empty result behavior, but sufficient for a list operation.
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 compact sentences, each adding value: action and pagination, then mapping and tier. No fluff, front-loaded with core 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?
No output schema, but description covers pagination and read-only nature. Could mention default fields returned, but overall complete for a list tool with optional params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 67% coverage; description adds context that pagination is Relay-based (relating to after and first). Fields param is described in schema. Description effectively complements but doesn't add extensive new info.
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?
Clearly states 'List quotes/estimates' with specific verb and resource. Mentions Relay-pagination and maps to GraphQL query, distinguishing from get_quote (single item retrieval).
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?
Implies usage for paginated listing via Relay, and tier readonly-owner suggests read-only context. No explicit when-to-use or alternatives like get_quote mentioned.
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:

[![backcrew-mcp-jobber MCP server](https://glama.ai/mcp/servers/jayson-svg/backcrew-mcp-jobber/badges/card.svg)](https://glama.ai/mcp/servers/jayson-svg/backcrew-mcp-jobber)

Score Badge

Copy to your README.md:

[![backcrew-mcp-jobber MCP server](https://glama.ai/mcp/servers/jayson-svg/backcrew-mcp-jobber/badges/score.svg)](https://glama.ai/mcp/servers/jayson-svg/backcrew-mcp-jobber)

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/jayson-svg/backcrew-mcp-jobber'

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