Awning

Update business details

owner_update_business

DestructiveIdempotent

Only for business owners signed in to Awning. Change name, description, street address and its map point, public contacts, cancellation rules or automatic confirmation. Pass lat and lng with a new address when you know them; without them the old map point is dropped. A new name for a live business is reviewed by Awning first: customers keep seeing the current name until the team approves it, and the response says so under rename — tell the owner. Sending the current name again withdraws a new name that is waiting; a change of letter case only goes through at once. What is sent replaces what is there. Confirm with the owner first. Use it for changes to a business that exists; during setup use owner_setup, and for services and prices owner_add_offering and owner_update_offering.

Input Schema

Name	Required	Description
`lat`	No	Latitude of the new address, when known
`lng`	No	Longitude of the new address, when known
`name`	No	The business's name. A live business keeps its current name until Awning approves a new one.
`address`	No	Street address, e.g. 'Bedford Avenue 120'. The city and country stay as they are.
`contacts`	No	Public contacts customers see: phone, whatsapp, telegram, instagram, website, email (public_email means the same as email). An empty string clears one; the ones not sent stay as they are.
`business_id`	No	Which business, when the owner runs several: business_id from owner_status. Leave out when there is only one.
`description`	No	What the business is, a few sentences
`auto_confirm`	No	True: bookings are confirmed at once. False: the owner confirms each request.
`late_fee_pct`	No	Share of the price kept for a later cancellation, in percent
`free_cancel_hours`	No	Free cancellation until this many hours before the start

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedOct 28, 2026
- addedInput schema / properties / address / description
```
Added value: +"Street address, e.g. 'Bedford Avenue 120'. The city and country stay as they are."
```
- addedInput schema / properties / auto_confirm / description
```
Added value: +"True: bookings are confirmed at once. False: the owner confirms each request."
```
- changedInput schema / properties / business_id / description
```
Previous value: -"Only needed if you manage several businesses"New value: +"Which business, when the owner runs several: business_id from owner_status. Leave out when there is only one."
```
- removedInput schema / properties / contacts / properties / email / maxLength
```
Removed value: -200
```
- removedInput schema / properties / contacts / properties / instagram / maxLength
```
Removed value: -200
```
- removedInput schema / properties / contacts / properties / phone / maxLength
```
Removed value: -200
```
- removedInput schema / properties / contacts / properties / public_email / maxLength
```
Removed value: -200
```
- removedInput schema / properties / contacts / properties / telegram / maxLength
```
Removed value: -200
```
- removedInput schema / properties / contacts / properties / website / maxLength
```
Removed value: -200
```
- removedInput schema / properties / contacts / properties / whatsapp / maxLength
```
Removed value: -200
```
- addedInput schema / properties / description / description
```
Added value: +"What the business is, a few sentences"
```
- addedInput schema / properties / free_cancel_hours / description
```
Added value: +"Free cancellation until this many hours before the start"
```
- addedInput schema / properties / lat / description
```
Added value: +"Latitude of the new address, when known"
```
- addedInput schema / properties / late_fee_pct / description
```
Added value: +"Share of the price kept for a later cancellation, in percent"
```
- addedInput schema / properties / lng / description
```
Added value: +"Longitude of the new address, when known"
```
- addedInput schema / properties / name / description
```
Added value: +"The business's name. A live business keeps its current name until Awning approves a new one."
```

Changed9 schema fields changedSep 29, 2026

addedInput schema / properties / address

Added value: +{
+  "maxLength": 200,
+  "type": "string"
+}

changedInput schema / properties / contacts / additionalProperties
```
Previous value: -{
-  "type": "string"
-}New value: +false
```

addedInput schema / properties / contacts / description

Added value: +"Public contacts customers see: phone, whatsapp, telegram, instagram, website, email (public_email means the same as email). An empty string clears one; the ones not sent stay as they are."

addedInput schema / properties / contacts / properties

Added value: +{
+  "email": {
+    "maxLength": 200,
+    "type": "string"
+  },
+  "instagram": {
+    "maxLength": 200,
+    "type": "string"
+  },
+  "phone": {
+    "maxLength": 200,
+    "type": "string"
+  },
+  "public_email": {
+    "maxLength": 200,
+    "type": "string"
+  },
+  "telegram": {
+    "maxLength": 200,
+    "type": "string"
+  },
+  "website": {
+    "maxLength": 200,
+    "type": "string"
+  },
+  "whatsapp": {
+    "maxLength": 200,
+    "type": "string"
+  }
+}

removedInput schema / properties / contacts / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
addedInput schema / properties / description / maxLength
```
Added value: +1000
```

addedInput schema / properties / lat

Added value: +{
+  "maximum": 90,
+  "minimum": -90,
+  "type": "number"
+}

addedInput schema / properties / lng

Added value: +{
+  "maximum": 180,
+  "minimum": -180,
+  "type": "number"
+}

addedInput schema / properties / name / maxLength
```
Added value: +120
```

First observedSep 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructiveHint=true, and the description explains exactly what makes it destructive: 'What is sent replaces what is there' and dropping lat/lng discards the old map point. It additionally discloses a behavior no annotation could convey — a new name on a live business is moderated, customers see the old name until approval, the response flags it under rename, and resending the current name withdraws a pending rename.

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 the access precondition and the change surface, then the high-risk rename and map-point caveats, then sibling routing. Every sentence carries information, though the rename paragraph is dense enough that the moderation rule and the withdrawal rule run together and cost a little readability.

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 10-parameter destructive mutation with no output schema, the description covers permissions, replace-not-merge semantics, the async rename outcome and where it appears in the response, the map-point side effect, and confirmation expectations. Nothing an agent needs to call it safely is missing.

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, but the description adds genuine semantics beyond it: the lat/lng pair must accompany a new address and omitting them drops the existing map point, and name changes have case-only fast-path versus moderated behavior. It does not add anything for contacts, late_fee_pct, or free_cancel_hours beyond what the schema already says.

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?

States a specific verb+resource (update business details) and enumerates the mutable surface: name, description, address and map point, contacts, cancellation rules, auto confirmation. It explicitly carves out the sibling tools for setup and offerings, so an agent can route without opening the schema.

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?

Gives a hard precondition ('Only for business owners signed in to Awning') and explicit alternatives with the conditions that select them: owner_setup during setup, owner_add_offering/owner_update_offering for services and prices. It also tells the agent to confirm with the owner before calling, which is a usage constraint, not just context.

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

All Awning tools Inspect

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

Need Help?