jobber-mcp

by chrischall

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each list tool targets a distinct Jobber resource (appointments, invoices, quotes, work requests), and read_page is clearly a generic fallback for detail pages. list_hubs and healthcheck serve configuration and diagnostics, so no two tools overlap in purpose.
Naming Consistency4/5
Most tools follow a jobber_verb_noun pattern (jobber_list_appointments, jobber_read_page), but jobber_healthcheck breaks the pattern by using a single compound noun instead of a verb. Still, the prefix and overall style are consistent enough to be predictable.
Tool Count5/5
Seven tools is well within the ideal 3-15 range and each one covers a specific aspect of the Jobber Client Hub without redundancy. The scope is clearly read-only, and the count feels appropriate for that purpose.
Completeness4/5
The server covers all major read-only views (appointments, invoices, quotes, work requests) plus a generic page reader for details. It lacks some potential features like search or filters, but for a read-only hub access tool, core coverage is solid with no dead ends.
Average 4.3/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 19 commits in the last 12 weeks
- Last stable release on August 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds a specific behavioral constraint ('approving a quote is not possible') and clarifies the output fields ('number, subject, section (approval state) and the raw metadata rows'), which goes beyond the annotations and helps set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every sentence adds value. No fluff or redundancy.
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?
With no output schema, the description compensates by naming the returned fields and the read-only limitation. The tool is simple (one optional parameter), and the description covers its main behavior and constraints. Minor gaps like pagination or hub-specific behavior are not addressed, but the annotations (openWorldHint) and schema fill some gaps.
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% for the single optional 'hub' parameter, so the schema fully explains the parameter. The description does not add any additional parameter semantics, but the baseline of 3 applies due to high schema coverage.
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 quotes a provider has sent through Jobber, naming specific fields (number, subject, section/approval state) and raw metadata rows. It distinguishes itself from sibling list tools (appointments, invoices, work requests) by explicitly focusing on quotes.
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 alternative guidance is provided. The tool's purpose is implied by the name and description (use for listing quotes), and the read-only caveat warns against expecting approval functionality. However, alternatives are not mentioned, so guidance is only implicit.
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 mark the tool as read-only and idempotent, and the description reinforces this with 'Read-only.' Beyond annotations, it adds scoping ('you have raised') and return contents ('current section (state) and metadata rows'), which provides useful context 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 concise sentence, front-loaded with the core purpose and no filler or redundant explanations. Every word contributes to understanding the tool's function.
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, the description covers the essential context: what is listed, scope, and what is returned. It does not mention pagination or details about 'metadata rows,' but the annotations and optional parameter make this adequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional parameter 'hub' is fully described in the schema ('Which provider hub to read, by label. Omit when only one is configured.'). The tool description adds nothing beyond the schema, so the baseline score of 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 lists 'work requests you have raised with a provider through their Jobber Client Hub' with their current state and metadata rows. It uses a specific verb and resource, and explicitly distinguishes from sibling list tools by focusing on work requests instead of appointments, invoices, quotes, or hubs.
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 is provided. The description implies use for viewing work requests submitted via a provider hub, but it does not contrast with alternatives or state exclusions, leaving the agent to infer usage from the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint by detailing the invoice structure: number, subject, list section, and raw metadata rows in `details`, including the caveat that amounts/dates are kept raw due to state-dependent row appearance. This adds genuine transparency about data fidelity and variability.
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?
Two sentences, front-loaded with scope, and the second sentence packs essential details without fluff. The first sentence is a fragment ('Invoices a provider has sent...') rather than a complete sentence, slightly reducing clarity.
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 there is no output schema, the description compensates by explaining the return content and the raw metadata behavior. It omits pagination or any limits, but for a simple list tool with strong annotations, it's sufficient.
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 100% schema coverage and a clear description for the `hub` parameter, the description need not add more. It doesn't, so a baseline of 3 is appropriate.
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 defines the tool's scope as invoices sent through Jobber and distinguishes it from sibling tools for appointments, quotes, and work requests. However, it lacks an explicit verb ('lists', 'returns'), relying on the title for the action, and instead starts with a noun phrase.
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 clearly signals context: it's for invoices a provider has sent, and explicitly states 'Read-only; this cannot pay anything,' which warns against using it for payment actions. It does not name specific alternative tools, but the separation from sibling list tools is implicit.
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 and idempotentHint, so the description adds value by noting that hub IDs are never returned because they are credentials, and that there is no combined multi-provider view. These are important behavioral constraints beyond the annotation metadata.
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 three sentences, front-loaded with the core purpose, and every sentence adds meaningful information. There is no redundancy or filler.
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 read-only list tool with no output schema, the description adequately conveys what is returned (labels, default indicator) and key limitations (no combined view, never returns IDs). It gives the agent enough context to decide when and how to use the 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?
The tool has zero parameters, so the description carries no parameter documentation burden. The baseline for zero-parameter tools is 4, and the description appropriately focuses on output and behavior rather than 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 the tool's function: listing configured provider hubs by label and indicating the default. It distinguishes itself from sibling list tools (appointments, invoices, etc.) by focusing specifically on hubs.
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 provides helpful context (each business has its own hub, no combined view) but does not explicitly state when to use this tool versus alternatives. It implies usage when hub configuration information is needed, but lacks explicit exclusions or alternative tool references.
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, openWorldHint, and idempotentHint. The description adds value by disclosing that it reports which layer failed and next steps, plus the hub-configuration condition. No contradiction found.
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 cover purpose, conditionality, output, and safety without wasteful repetition, keeping every phrase meaningful.
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?
Although no output schema exists, the description clearly states what is checked and what is reported (failed layer and remediation). It avoids overspecifying an internal format, which is acceptable for a diagnostics tool, but could mention whether a hub absence changes output.
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?
With zero parameters, the baseline is 4 per the rubric. The description needs no parameter-level elaboration since there is nothing to configure, and the schema's 100% coverage trivially satisfies requirements.
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 ('Checks') and identifies precise resources (fetchproxy browser bridge, hub appointments page), clearly distinguishing it from the list/read siblings by focusing on reachability verification.
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?
It clearly implies this tool is for diagnosing connectivity before using functional tools, and conditionally checks the hub only if configured. However, it does not explicitly state when to use it over alternatives or mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, idempotent), the description discloses output grouping, the included fields, and the null behavior for time when the provider chooses not to show times. This adds valuable context about what the agent should expect from the response.
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 and front-loaded, with three sentences that each add meaningful content: what the tool does, what data is returned, and a specific edge case. No filler or redundancy.
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?
With no output schema, the description does a good job explaining the return values (grouped visits, fields, null time). It lacks some details like pagination or whether all visits are returned, but for a simple read-only list tool with one optional parameter, it is largely 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?
The schema description covers the single 'hub' parameter fully (100% coverage), including its optionality. The tool description does not add parameter-level meaning, but the schema already provides sufficient guidance, so a baseline 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 lists scheduled visits from a provider's Jobber Client Hub, grouping them into Today/Upcoming/Past. This uses a specific verb and resource, and the grouping detail distinguishes it from sibling tools that list invoices, quotes, and work requests.
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 on what the tool returns (scheduled visits) and how they are organized, making it obvious when to use it. It does not explicitly name alternatives or exclusions, but the sibling tools are distinct enough that no added guidance is necessary.
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, openWorldHint, and idempotentHint. The description adds meaningful behavioral context by specifying that the output is 'readable text' and that the tool works for arbitrary pages. It also reinforces the read-only nature, matching the annotations without contradicting them.
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 only three sentences, leads with the core purpose, embeds examples naturally, and includes the safety note 'Read-only.' There is no redundant or filler content.
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 is simple (two params, no output schema) and annotations are strong, the description adequately covers scope, usage, and return nature. It could mention error behavior or more return details, but it is sufficiently complete for an agent to invoke it correctly.
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 100%, with descriptions for both 'hub' and 'path'. The description supplements this with concrete path examples ('invoices/150208512', 'appointments/2236612358') and explains when to omit 'hub', adding practical usage value beyond the schema fields.
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 starts with a clear verb and resource: 'Fetch any page of a Jobber Client Hub and return its readable text.' It explicitly distinguishes this tool from list siblings by stating it is for unpinned-schema detail pages and as a fallback when list tools return nothing.
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 gives direct usage guidance: 'Use for detail pages ... whose layout has no pinned schema, and to inspect a page when a list tool returns nothing.' This clearly tells an agent when to choose this tool over the sibling list tools, even if it doesn't name them explicitly.
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:

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

Score Badge

Copy to your README.md:

[![jobber-mcp MCP server](https://glama.ai/mcp/servers/chrischall/jobber-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/jobber-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/chrischall/jobber-mcp'

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