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., "@singleops-mcp Find client by email jane@example.com"
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.
First MCP server for the SingleOps Public API — let Claude, Cursor, or any MCP client read operations, look up clients, and create leads in SingleOps, the leading US green-industry field-service platform (landscaping, tree care, irrigation, lawn care, sod farms), part of Granum (1,000+ customers).
SingleOps is the operations backbone for thousands of tree-care companies,
lawn-care operators, and full-service landscaping businesses across the US
and Canada. The public REST API at app.singleops.com/api/v1/ has been
documented since the mid-2010s, but until now no one had wrapped it for
MCP clients. The fitness/wellness MCP space is saturated (Mindbody, Glofox,
Wodify, PushPress, etc. all have multiple wrappers), but the green industry
is wide open.
The same MCP works across the SingleOps and Granum family because Granum (acquired SingleOps) and LMN share infrastructure. Tools that help an arborist or lawn-care owner get a lead into the system in 30 seconds from their phone or browser are an obvious fit for AI agents.
Related MCP server: Jobber MCP Server
You: "What divisions does our account have?"
Claude: *calls list_operations, returns Maintenance / Install / Irrigation*
You: "Did we already quote Jane Doe? Her email is jane@example.com."
Claude: *calls search_clients_by_email, finds client_id 42*
You: "Create a new lead for client 42 in the Maintenance division for a backyard cleanup."
Claude: *calls create_lead_for_existing_client, returns the new lead id*
You: "New lead from a phone call — John Smith at 555-123-4567, wants irrigation estimate."
Claude: *calls create_lead_with_new_client with the new client details*pip install -e ".[dev]"SingleOps uses an user_email + user_token pair (NOT a bearer token).
Contact support@singleops.com to provision an API user on your account.
API access is gated to the MAX plan (the doc explicitly states: "API
access may not be available on all pricing tiers").
export SINGLEOPS_USER_EMAIL="api+youraccount@singleops.example.com"
export SINGLEOPS_USER_TOKEN="<secret-token-issued-by-singleops-support>"Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"singleops": {
"command": "singleops_mcp",
"env": {
"SINGLEOPS_USER_EMAIL": "api+youraccount@singleops.example.com",
"SINGLEOPS_USER_TOKEN": "<your-token>"
}
}
}
}Tool | Purpose |
| Verify the credentials work. If this fails, all other tools will too. |
| List the divisions configured in your account (e.g. Maintenance, Install, Irrigation). |
| List the per-account custom fields that augment the default lead/job/client schema. |
| Find clients by email (prefix match, up to 50 per page). |
| Find clients by phone (prefix match, up to 50 per page). |
| Create a lead attached to an existing client record. |
| Create a new client + lead in a single call. |
SingleOps's public REST API is at https://app.singleops.com/api/v1/. The
MCP wraps:
GET /operations — list divisions
GET /custom_inputs — list custom field definitions
GET /clients/search_by_field?search_field=email|phone&search_term=...&page=... — search clients
POST /jobs — create a new lead (either for an existing client or with a new client profile)
33 tests via respx + hypothesis, 0% live API calls
ruff (full rule set) + mypy --strict + ruff-format all clean
Typed exception hierarchy (SingleopsAuthError, SingleopsNotFoundError, SingleopsRateLimitError, SingleopsAPIError, SingleopsConnectionError)
isError-compliance: tools raise (not return) on failure, so FastMCP sets isError: true on the wire (per the Blackwell MCP security audit)
JSONL audit logging per tool call with secret redaction (user_token, email, phone, mobile all stripped)
Retry with exponential backoff + full jitter, honoring Retry-After
MIT — see LICENSE.
Create a lead (Job) for an existing client already in SingleOps.
Use after search_clients_by_email / search_clients_by_phone to
attach a new lead to an existing client record. The lead moves
through the SingleOps Job workflow (Lead -> Proposal -> Schedule ->
Complete -> Invoice).
client_id is the SingleOps client.id (NOT email, NOT name). Look it
up with one of the search tools first.
operation_id is the SingleOps operation.id for the division the work
belongs to (look it up with list_operations).
visit_stage_id defaults to 8 (the standard "Lead" stage) but can be
set to whatever stage IDs your account has configured.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| tags | No | ||
| notes | No | ||
| client_id | Yes | ||
| operation_id | Yes | ||
| sales_rep_id | No | ||
| visit_stage_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. Explains the lead workflow (Lead -> Proposal -> Schedule -> Complete -> Invoice), default stage, and that `client_id` is numeric. Does not mention output or side effects, but overall transparent for a creation 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?
Well-structured with bullet-like points. Every sentence adds value; front-loaded with main purpose. Could be slightly shorter, but remains efficient.
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?
With 7 parameters, no schema description, and no annotations, the description adequately covers the core workflow and prerequisites. However, lacks explanation for several optional parameters and does not reference the output schema or `list_custom_inputs` for extra fields.
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 coverage is 0%, so description must compensate. Explains `client_id`, `operation_id`, and `visit_stage_id` with context. However, `name`, `tags`, `notes`, and `sales_rep_id` are left undocumented, leaving gaps.
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 'Create a lead (Job) for an existing client already in SingleOps' with specific verb and resource. Distinguishes from sibling tool `create_lead_with_new_client` by emphasizing the client must exist.
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?
Explicitly instructs to use after `search_clients_by_email` or `search_clients_by_phone`, and to look up `operation_id` via `list_operations`. Provides workflow context and warns about `client_id` type, making when-to-use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a lead (Job) for a brand-new client, in a single call.
Use this when the prospect is NOT yet in SingleOps. The new client profile is created under the "portal_lead" object inside the same request — the lead is attached to that new client automatically.
At minimum pass first_name + last_name. Providing email or phone is strongly recommended so SingleOps can later deduplicate if the same person contacts you again.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| tags | No | ||
| No | |||
| notes | No | ||
| phone | No | ||
| mobile | No | ||
| address | No | ||
| last_name | Yes | ||
| first_name | Yes | ||
| bill_addr_1 | No | ||
| bill_addr_2 | No | ||
| company_name | No | ||
| operation_id | Yes | ||
| sales_rep_id | No | ||
| bill_addr_city | No | ||
| visit_stage_id | No | ||
| bill_addr_state | No | ||
| bill_addr_postal_code | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It discloses key behaviors: creates client profile under 'portal_lead' and auto-attaches the lead, and mentions deduplication via email/phone. However, it omits side effects, auth requirements, rate limits, and error conditions, leaving significant transparency gaps.
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?
Six sentences conveying all critical information without redundancy. Key details are front-loaded: purpose, usage condition, minimal requirements, and a recommendation. Every sentence earns its place.
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 lacks coverage for the 18-input parameters and behavioral context (e.g., what happens on error, how operation_id is used). The sibling tool distinction is clear, but parameter and behavioral details are insufficient for an agent to use the tool correctly without guessing.
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 but only explains first_name, last_name, email, and phone (and implies operation_id as required). The other 14 parameters (e.g., tags, notes, address fields) are completely unmentioned, failing to guide their usage.
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 verb (create), resource (lead for new client), and differentiates from the sibling tool create_lead_for_existing_client by specifying 'when the prospect is NOT yet in SingleOps'. The context of a single call is also highlighted.
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?
Explicitly advises to use when the client is new, recommends minimum fields (first_name, last_name), and suggests email/phone for deduplication. The sibling tool is implicitly referenced by the name create_lead_for_existing_client, but not mentioned directly in the description, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify credentials work. If this fails, all other tools will too.
Hits /operations as a low-cost liveness probe (a single small GET that exercises the auth + network path).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: low-cost GET to /operations, exercises auth+network path. No contradictions.
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 sentence, front-loaded purpose, no wasted words. Every sentence adds value.
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?
For a simple health check with no parameters and an output schema, the description completely covers purpose, behavior, and context.
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?
No parameters exist, baseline is 4. Description does not need to add parameter info.
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 verifies credentials and acts as a liveness probe. It contrasts with sibling tools which deal with leads, clients, etc., making purpose distinct.
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 the tool should be used to check if credentials work before using other tools, and notes that failure means all others fail. No explicit when-not or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List custom input fields configured for the account.
Custom inputs are per-account fields that augment the default lead/job/ client/item schema — e.g. "Lead Source", "Property Acreage", "Service Tier". Each entry has a key, label, type, and the entity it applies to. Cache this list; the lead-creation endpoint accepts custom field values keyed by the custom input's key.
| 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, so the description carries the burden. It describes a read-only list operation without mentioning side effects or safety, but the action 'list' inherently implies non-destructive behavior. Additional context about rate limits or authorization would improve transparency.
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 concise with three sentences, each adding meaningful information: purpose, explanation of custom inputs, and usage advice. No extraneous 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?
Given the tool has no parameters and an output schema exists, the description sufficiently covers what the tool does and how to use the result, with no missing context.
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 no parameters (100% schema coverage isn't applicable but effectively no params), the description adds no parameter-specific guidance, which is acceptable given there are no parameters to document.
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 'List custom input fields configured for the account', providing a specific verb and resource. It also explains what custom inputs are with examples, distinguishing it from sibling tools like 'create_lead_for_existing_client' 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 advises caching the list and notes its relevance to lead-creation, guiding usage. It lacks explicit when-not-to-use instructions, but the context and sibling tools make the intent clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List operations (divisions) configured in the account.
Operations are the divisions a green-industry business runs under — e.g. "Maintenance", "Install", "Irrigation", "Tree Care", "Snow". Each lead (Job) must be assigned to exactly one operation, so this list is the entry point for any lead-creation flow.
Returns the list of operation objects with id, name, and any division- specific metadata the account has configured.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It states the tool returns a list of operation objects with id, name, and metadata. For a read-only list operation, this is sufficient behavioral disclosure.
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?
Three well-structured paragraphs: front-loaded purpose, clear context, and return format. Every sentence adds value with no redundancy.
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 output schema exists, description adequately covers purpose, usage context, and return fields. Complete for a simple list 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?
No parameters exist; schema coverage is 100%. Baseline 4 for zero parameters is appropriate as description adds no param info but none is needed.
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 operations (divisions), explains what operations are with examples, and explicitly distinguishes from sibling tools by calling it the entry point for lead-creation flows.
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 indicates when to use: 'entry point for any lead-creation flow'. It provides good context but does not explicitly say when not to use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find clients by email address (prefix match, up to 50 per page).
Use this before creating a lead to check whether the prospect already
exists in the SingleOps account. Returns 0-50 matching clients;
paginate with the page parameter when the count approaches 50.
Common pattern: search the prospect's email; if found, reuse
client_id when creating the lead instead of supplying a portal_lead
block.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context: prefix match, 50-per-page limit, pagination with page parameter, and return of 0-50 clients. No annotations provided, so description carries full burden and covers key behaviors.
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?
Four sentences, well-structured, front-loaded with main purpose, then usage pattern. 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?
Covers all needed context: when to use, how to paginate, relation to siblings, return count. Has output schema so return details not needed in description.
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 coverage is 0% (no descriptions in schema). Description compensates by explaining email is prefix match, page is for pagination with default 1. Adds meaning beyond bare 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?
Clearly states 'Find clients by email address (prefix match, up to 50 per page)'. Specifies verb (find), resource (clients), and scope (email, prefix, limit). Distinguishes from sibling search_clients_by_phone.
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?
Explicitly says 'Use this before creating a lead to check whether the prospect already exists'. Provides common pattern: search, if found reuse client_id, else use portal_lead. Mentions pagination when count approaches 50.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find clients by phone number (prefix match, up to 50 per page).
Use this when a prospect's email is unknown (e.g. a phone call comes in) to find their existing record before creating a new lead. Sometimes clients have multiple phone numbers or extensions, so the prefix match lets the search catch those variations.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| phone | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses prefix-match logic, page limit of 50, and lack of pagination details like sorting. While adequate for a read-heavy search, it omits whether results are ordered or what fields are returned (though output schema may cover this).
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?
Three sentences with no fluff. The first sentence fronts the main purpose and constraints. The second provides a usage scenario. The third explains the design rationale. Every sentence adds value.
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 low complexity (2 params, no annotations, output schema present), the description covers the core behavior and use case well. It lacks details on result ordering or handling multiple matches, but is complete enough for most scenarios.
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 must explain parameters. It explains 'phone' (prefix match) but does not explicitly describe the 'page' parameter, only implying pagination via 'up to 50 per page'. The baseline for low coverage is low, and the description only partially 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?
The description clearly states 'Find clients by phone number (prefix match, up to 50 per page).' This specifies the verb (find), resource (clients), and key constraints (prefix match, page limit). The tool name and sibling search_clients_by_email provide implicit differentiation.
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 explicitly states when to use this tool: 'when a prospect's email is unknown (e.g. a phone call comes in) to find their existing record before creating a new lead.' It also explains the rationale for prefix matching, giving agents clear context for invocation.
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.0create_lead_for_existing_clientcreate_lead_with_new_clienthealth_checklist_custom_inputslist_operationssearch_clients_by_emailsearch_clients_by_phoneScored across 7 tools
Each tool has a clearly distinct purpose: two lead creation variants for existing vs. new clients, two search methods by email/phone, two list tools for operations and custom inputs, plus a health check. No overlap or ambiguity.
Most tools follow a verb_noun snake_case pattern (create_lead_, search_clients_, list_). 'health_check' deviates as noun_noun but is a standard term. Overall consistent and predictable.
Seven tools is well-scoped for a focused CRM server covering lead creation, client lookup, and account configuration. It's neither too few nor too many.
The set covers lead creation and client search but lacks tools to update, delete, or list leads, and no tool to get lead details. Agents cannot manage leads beyond creation, which is a significant gap for a lead-management system.
Search, summarize, and update your RevOrbit CRM (leads, deals, contacts, tasks) in plain language.
Search customers, manage quotes, work orders, action items, and calendar events for your business
Streamline your Attio workflows using natural language to search, create, update, and organize com…
Automate eSignature workflows and signing tasks via natural language commands.
