Skip to main content
Glama
Sign In

Conciergr

by com.conciergr
OverviewDiscussionsAdmin

Change settings

update_settings
Destructive

Change any of the assistant's settings and the business's details. Send only the fields to change; a field left out keeps its value, and an empty string clears it. Numbers to ignore is the whole list. Branches, payment accounts and documents to send have their own tools (save_branch, save_payment_account, save_document and their remove_ tools), one item at a time, so changing one never drops the others. Nothing is saved if any field is refused; the refusal says which and why.

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": "update_settings"
  }
}

Input Schema

NameRequiredDescriptionDefault
brandNoWhich assistant (its slug from get_overview `brands[].slug`). Leave out when the business has one.
mainLineNoThe number customers call, given out when asked, with the country code (like 6591234567). Empty means the assistant's own WhatsApp number, right for most businesses.
timezoneNoThe business's local time, for "open now", "tomorrow" and reminders.
ownerNameNoWho Conciergr addresses service updates to.
teamHoursNoWhen the team answers WhatsApp, in the business's timezone; outside them the assistant tells customers when the team is back. Give all seven days (mon to sun), each a range or closed; null for all days clears it.
otherEmailNoNon-customer enquiries that fit neither of the above. An empty category email turns off awareness emails for that category.
reviewLinkNoWhere a happy customer leaves a public review (for example the Google review link). The fallback for branches without their own. Without any, review asks wait.
signupLinkNoWhere a new customer signs up: enrolment form, membership page or checkout. Follow-up messages carry it; without it (and without an enrolment form among the documents to send) the follow-ups after a visit wait.
websiteUrlNoThe business's public website.
bookingLinkNoThe booking page (SimplyBook, Calendly, Fresha and the like). Needed when bookingStep is link.
bookingStepNoHow customers book a first visit (a trial, visit, assessment or appointment): chat = the assistant books them in chat from the business's timetable; link = they book at the business's own booking link (needs bookingLink) and the assistant never says "you're booked"; team = the assistant takes the details and hands over to the team.
vendorEmailNoBusinesses trying to sell to this business are emailed here, never pinged to staff.
bookingEmailNoWhere booking requests are emailed. Empty: the alert email.
businessNameNoThe name the assistant says it is from, and the name on our emails. The name customers know. Up to 80 characters. (Some older accounts can't change it here.)
assistantNameNoThe assistant's one first name, like Mei or Sam (at most two words). Not the business name. Empty: it introduces itself as Ana.
documentsEmailNoWhoever keeps the Doc and Sheet up to date: the weekly report and any problem with the documents go here and to the alert email. Empty: the alert email only.
openingMessageNoSent word for word as the first message to anyone new (or quiet for 14+ days), followed at once by the answer to what they wrote. Keep it to a greeting and one question. Up to 1,000 characters. Empty: the assistant simply answers. The business should switch off WhatsApp Business's own greeting.
paymentDetailsNoHow customers pay, in the business's words (PayNow, bank transfer, a payment link, cash at the centre). Sent word for word once a customer wants to go ahead, when a paid booking is confirmed, or when asked how to pay. Write {mobile} where the customer's own mobile number goes (for example Reference: {mobile}). Up to 1,000 characters. This is account 1; other accounts go in payeeGroups.
excludedNumbersNoStaff or franchisee WhatsApp numbers the assistant must never reply to (the team answers them in person). Digits with country code. The whole list: send every number to keep.
ownerAlertEmailNoWhere billing and service notices go, and the fallback for any email left empty.
recruitmentEmailNoJob applicants and hiring enquiries are emailed here instead of messaging staff.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is known. The description adds genuinely useful behaviour beyond that: nothing is saved if any field is refused, and the refusal names the field and reason, plus the whole-list replacement risk on excludedNumbers. However, the strongest gap for a destructive, open-world mutation is left implicit 4 the description never states what is being overwritten or that a cleared field is permanent loss of prior value.

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?

Front-loaded with purpose, then update semantics, then the sibling-tool boundary, then the atomicity guarantee 4 a sensible ordering with little waste. The branch/payment/document sentence is the longest and lists tool names an agent can already see in the sibling list, so it is slightly over-explained.

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 21-parameter, zero-required mutation with no output schema, the description covers the update model, clearing, list replacement, error atomicity and tool boundaries well. It is silent on what a successful response returns and on any permission or scope requirements, which are the remaining unknowns before calling.

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 baseline is 3; the description earns more by adding semantics the schema cannot express: omission preserves, empty string clears, and excludedNumbers replaces the entire list rather than merging. That whole-list rule is the single most misinvokable behaviour in this schema and it is called out explicitly.

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?

Opens with a specific verb+resource ("Change any of the assistant's settings and the business's details") and explicitly excludes branches, payment accounts and documents in favour of save_*/remove_* siblings. It does not distinguish itself from the narrower setting tools in the sibling list (set_tone, set_topics, set_signoff, pause_assistant), so an agent cannot fully tell from the description alone which surface owns tone or topics.

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?

Gives explicit operating rules: send only the fields to change, omit to keep, empty string to clear, excludedNumbers is a whole-list replacement, and one-at-a-time edits of branches/accounts/documents belong to their own tools. What is missing is guidance against the tone/topics/signoff siblings, which overlap this tool's stated scope.

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

All Conciergr toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources