Skip to main content
Glama

Add or change a service provider

save_provider

Adds a service provider — a plumber, the HVAC company, an electrician — with their trade and contact details, or, with id, changes one (a new phone number, a different contact).

Instructions

Adds a service provider — a plumber, the HVAC company, an electrician — with their trade and contact details, or, with id, changes one (a new phone number, a different contact). To add: name; check list_providers first so you don't add one twice, then use its id as providerId on save_maintenance or complete_maintenance. To change: fields left out stay as they are; null clears one. Returns the provider with its id.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "save_provider"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoThe provider to change, from list_providers; leave out to add a new one
nameNoThe business or person: "Acme Heating & Air"
emailNoEmail address
notesNoAnything worth remembering: rates, who to ask for, what they did well
phoneNoPhone number, as they give it
tradeNoWhat they do: "Plumber", "HVAC", "Appliance repair"
addressNoTheir business address
websiteNoTheir website
contactNameNoWho to ask for

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2026.11.10

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), it discloses the partial-update contract — omitted fields are preserved, null clears a field — and states the return value includes the id. That is real behavioral context an agent cannot infer from the annotations, though it does not address whether clearing contact data is recoverable.

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 tight sentences front-load the add/change distinction, then the duplicate-check workflow, then the mutation semantics. No filler and nothing repeated from the schema.

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?

With nine all-optional parameters and no output schema, the description covers the create-vs-update branch, the null-clearing rule, the prerequisite lookup, and the return shape — everything needed to call 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%, so the schema already carries per-field meaning; the description still adds value by explaining that id omission switches the operation to create and that null versus omission have different effects — semantics the schema alone does not convey.

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 names a specific verb and resource ("Adds a service provider ... or, with id, changes one") and gives concrete examples of the resource (plumber, HVAC company, electrician), so the upsert behavior is unambiguous and distinguishable from siblings like save_maintenance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly routes the agent: check list_providers first to avoid duplicates, then pass the returned id as providerId on save_maintenance or complete_maintenance. Both the when-to-use and the downstream dependency are stated outright.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.