Skip to main content
Glama
Sign In

Awning

by help.awning
OverviewDiscussionsAdmin

Schedule

owner_get_schedule
Read-only

Only for business owners signed in to Awning. Day or week view per staff member, room or rental pool: bookings, classes, blocked time and free windows. Every entry in resources carries an id: pass it as resource_id here to see just that one, or to owner_block_time and owner_set_schedule to change it. Use it to see how a day or week looks; for requests waiting for an answer use owner_list_bookings.

Input Schema

NameRequiredDescriptionDefault
dateNoFirst day to show, YYYY-MM-DD, in the business's time zone. Default today.
daysNoHow many days from `date`, 1 to 7. Default 1.
business_idNoWhich business, when the owner runs several: business_id from owner_status. Leave out when there is only one.
resource_idNoShow only this staff member, room or rental pool: an id from `resources` in an earlier answer. Default: all of them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • 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."
    • changedInput schema / properties / date / description
      Previous value: -"YYYY-MM-DD, default today"New value: +"First day to show, YYYY-MM-DD, in the business's time zone. Default today."
    • addedInput schema / properties / days / description
      Added value: +"How many days from `date`, 1 to 7. Default 1."
    • addedInput schema / properties / resource_id
      Added value: +{
+  "description": "Show only this staff member, room or rental pool: an id from `resources` in an earlier answer. Default: all of them.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the description doesn't need to prove safety. It adds the audience gate ('Only for business owners signed in to Awning') and clarifies that 'resources' entries carry ids that feed resource_id here and mutation tools elsewhere – real context beyond the structured fields.

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?

Four sentences, each carrying distinct information: audience, view scope, id chaining, and sibling routing. The audience restriction is front-loaded, though the id-chaining sentence is slightly long-winded for what it conveys.

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?

Covers the audience, the granularity of the view, what data appears in it, and how resource_id connects to other tools. With no output schema, a brief note on response shape would help, but nothing essential for calling it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so date, days, business_id and resource_id are already documented with defaults and formats. The description's note about resource_id echoes what the schema already says ('an id from resources in an earlier answer'), adding little new meaning. Baseline 3 applies.

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-and-resource ('Day or week view per staff member, room or rental pool') and enumerates what the view contains: bookings, classes, blocked time and free windows. An agent can distinguish it from get_availability or owner_list_bookings 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 Guidelines4/5

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

Gives an explicit use case ('Use it to see how a day or week looks') and names the alternative for a related need ('for requests waiting for an answer use owner_list_bookings'). It does not address the other near-neighbours such as get_availability, but the primary routing decision is covered.

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

All Awning 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