Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jobber-mcp Show me every active job assigned to Alex."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol (MCP) server for Jobber — home service business management software (HVAC, plumbing, landscaping, etc.).
Talk to Jobber from Claude, Cursor, or any MCP client. Read clients, jobs, quotes, invoices; create new clients and add notes. GraphQL API via OAuth2 bearer token.
Built against the Jobber Developer API. No existing MCP for Jobber — this is the first.
You: "Show me every active job assigned to Alex."
Claude: *list_jobs(status="active") then filters by assignedTo*
You: "Find every quote awaiting response for over 7 days."
Claude: *list_quotes(status="awaiting_response") then filters by createdAt*
You: "Add a note to client 12345: 'Replaced capacitor, system running.'"
Claude: *add_client_note with body*
You: "Create a new client: Sarah Chen, sarah@example.com, 555-0101."
Claude: *create_client*Related MCP server: MCP Moloni ON
pip install -e .You need an OAuth2 access token. Get one via the Jobber OAuth flow — register your app, complete the install dance, store the returned token.
export JOBBER_ACCESS_TOKEN="..."For multi-tenant apps, run multiple MCP server instances — each with its own token. Jobber's tokens expire; you'll need to refresh on your backend and restart the MCP server.
{
"mcpServers": {
"jobber_mcp": {
"command": "jobber_mcp",
"env": {
"JOBBER_ACCESS_TOKEN": "..."
}
}
}
}Tool | Type | What it does |
| Diagnostic | Verifies token |
| Read | Homeowners / businesses |
| Read | Work orders (filterable by status) |
| Read | Quotes (filterable by status) |
| Read | Invoices (filterable by status) |
| Write | New client |
| Write | Note on client record |
Jobber's API is GraphQL-only. The advantage: one HTTP endpoint, ask for exactly the fields you need, no over-fetching, no under-fetching. The MCP tools use minimal field selections so the agent gets the data it needs without pagination churn.
pip install -e ".[dev]"
pytest
jobber_mcpI build production-grade MCP servers for vertical SaaS — insurance, dental, veterinary, legal, property mgmt, home services. Typical engagement: 2-4 weeks, $25K-$120K. Source-owned, MIT-licensed, no vendor lock-in.
See sanjibani/mcp-services or email sanjibani@users.noreply.github.com.
Ships in the sanjibani vertical-MCP portfolio — see also hawksoft-mcp, open-dental-mcp, ezyvet-mcp, jobber-mcp, paid-skills, mcp-vertical-template.
MIT.
Jobber for the GraphQL API + OAuth2 flow
Built using mcp-vertical-template (the GraphQL client is a small variation of the REST template)
Inspired by sanjibani/hawksoft-mcp and sanjibani/ezyvet-mcp
Add a note to a client's record. Useful after a phone call or site visit.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| pinned | No | ||
| client_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Add a note,' implying mutation, but does not explain whether notes are appended, overwritten, or if special permissions are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no unnecessary words, efficiently conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too minimal. It fails to explain the effect on the client record, the structure of the note, or any important details about parameters and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no information about the three parameters (body, pinned, client_id). The description does not compensate for the lack of documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a note to a client's record' with a specific verb and resource. It distinguishes itself from sibling tools like create_client and list_clients, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests usage 'after a phone call or site visit,' providing some contextual guidance. However, it does not explicitly state when not to use or mention any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new client (homeowner / business).
App-created clients are automatically tagged with your app's name in Jobber's Lead source field — this is the only way leads enter the system via your integration.
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| phone | No | ||
| last_name | Yes | ||
| first_name | Yes | ||
| company_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It reveals one key detail: app-created clients are auto-tagged with the app name in the lead source field. However, it does not mention idempotency, error handling, permissions, or what happens on duplicate input. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences), front-loaded with the core purpose, and includes a critical behavioral note. Every sentence adds value with no redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description omits parameter details and behavioral context (e.g., uniqueness constraints, error handling). For a tool with 5 parameters and 0% schema coverage, the description is incomplete and insufficient for an agent to use it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, placing full burden on the description to clarify parameters. The description provides no information about any of the five parameters (e.g., required first_name/last_name, optional email/phone/company_name). The schema property names are self-explanatory, but no added value is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a new client (homeowner / business).' It specifies the resource (client) and action (create), and the parenthetical distinguishes client types. Among siblings, only this tool creates clients, so it effectively differentiates itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: to create a new client/lead in Jobber, noting that it's the only way leads enter via integration. While it doesn't explicitly exclude alternatives, the context is clear for a creation tool among listing and note tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the access token is valid by listing 1 client.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses that it lists 1 client, which is a side effect, but does not explicitly state that it is a read-only or lightweight operation. Adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. Every word earns its place with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description sufficiently explains the tool's action. It could mention the return format, but the output schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters. According to rules, 0 params earns a baseline of 4. The description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: verifying token validity by listing one client. It distinguishes from sibling tools which focus on CRUD operations on clients, invoices, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to check token validity) but does not explicitly state when not to use or provide alternatives. Context is clear for this simple health check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List clients (homeowners/businesses you service) with their contact info.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It only states the basic action and output, omitting behavioral details like pagination (despite a limit parameter), ordering, or read-only nature. This is insufficient for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. It wastes no words, though it could benefit from additional detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values are covered. The tool is simple, but the description lacks mention of pagination or filtering constraints. For a list tool, it is minimally viable but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the single parameter 'limit', leaving its purpose unexplained. With 0% schema description coverage, the description should compensate but fails to add any meaning beyond the schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The name 'list_clients' and description 'List clients (homeowners/businesses you service) with their contact info.' clearly specify the verb ('list') and resource ('clients'), distinguishing it from siblings like create_client or list_invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving client contact info, and sibling names (list_invoices, list_jobs, list_quotes) suggest it's for clients specifically. However, it lacks 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.
List invoices with optional status filter.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but only says it lists invoices with an optional filter. It does not disclose pagination behavior, ordering, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence that is front-loaded with the primary verb and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits key details like default status behavior, limit's role (e.g., pagination), and any ordering. Not adequate for a full understanding of the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds meaning only for 'status' (optional filter) but does not explain 'limit' or allowed status values. Insufficient compensation for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists invoices and optionally filters by status, which is a specific verb+resource. It is clearly distinguishable from sibling list tools like list_clients or list_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of context, prerequisites, or when not to use it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List jobs (work orders).
Optional status filter — common values: active, awaiting,
completed, canceled, needsAttention.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond listing jobs with an optional status filter. Since no annotations are provided, the description should explain that this is a read-only operation returning a list, and mention any default or pagination behavior, but it does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. It front-loads the core purpose and immediately adds the optional filter, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but adequate given that an output schema exists and the tool has only two parameters. However, it lacks context about the scope of jobs listed (e.g., all jobs or per user) and does not mention related concepts like clients or work orders in broader system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate. It provides common values for the status parameter but does not explain its purpose or semantics for the limit parameter. This is insufficient for an agent to use the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists jobs (work orders), providing a specific verb and resource. It is distinguishable from sibling tools like list_clients and list_invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description only mentions an optional filter, with no context about typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List quotes with optional status filter.
Common statuses: awaiting_response, approved, declined,
converted, expires.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. Only mentions status filter, but omits pagination, ordering, rate limits, or whether it's read-only. Incomplete for safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key info. No wasted words, but missing important details for a complete description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given lack of annotations and low schema coverage, description should be more thorough. Does not explain pagination, output format, or limit scope. Agent may under-specify or misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description adds common status values for the status parameter, but gives no explanation for the limit parameter. Adds some value but not fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists quotes, with an optional status filter. Differentiates from sibling tools like list_clients or list_invoices by specifying the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lists common statuses, which helps in filtering, but does not specify when to use this tool versus alternatives. No guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_client_notecreate_clienthealth_checklist_clientslist_invoiceslist_jobslist_quotesScored across 7 tools
Each tool targets a distinct resource or action: client creation, note addition, health check, and lists for clients, invoices, jobs, and quotes. No overlap in functionality.
All tools follow a consistent verb_noun pattern in snake_case (e.g., list_clients, create_client, add_client_note), with health_check being the only slight deviation but still clear.
7 tools is a reasonable size for a focused CRM server, covering basic operations without being overwhelming. It could grow slightly but is well-scoped.
The server lacks update, delete, and creation tools for jobs, invoices, and quotes, limiting full lifecycle management. Only client creation and listing are covered.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
MCP server for Codat — companies, connections, invoices, bills and financial statements.
Public MCP server for discovering open jobs. Search, filter, and get application links.
MCP server for Linear project management and issue tracking
