Skip to main content
Glama
Sign In

Final POS – Custom POS Builder

by com.finalpos
OverviewDiscussionsAdmin

List tills

hub_get_stations
Read-only

Every POS station (till, register, checkout lane, cash desk) the merchant has — the same list as Run → Stations. Answers 'how many tills do I have', 'which register is busy right now', 'which store is this till at', 'which of them are browser tills'. Each station belongs to exactly ONE outlet and the outlet name is resolved here, so you do not need get_outlets to answer where a till stands — call get_outlets only to turn a store NAME the merchant said into the outletId filter of this tool. WHAT status MEANS, EXACTLY: the server does not compute it. The POS app on the till writes it — IN_USE when a cashier opens a register shift on that station, AVAILABLE when the shift is closed. It is best-effort: the update is lost while the device is offline and only flushed when it reconnects, and older app versions never sent it at all, so a station can sit at AVAILABLE with a shift open on it or at IN_USE hours after one was closed. Read it as "what this till last told us", never as proof. NEVER answer a shift or money question from it: for shifts that are actually open, who opened them and what they took, use get_sessions (a session with no closeTime is open) and get_session_report. If those disagree with this flag, they are right and the flag is stale. The whole list comes back in one call — it is short and plan-capped, there is no paging; search matches the station NAME only. Deleted stations are not returned.

Input Schema

NameRequiredDescriptionDefault
kindNonative = a physical device running the POS app; virtual = a browser till
searchNoFilter by station name, e.g. "POS 2"
statusNoIN_USE = the till last reported an open register shift; AVAILABLE = it did not
outletIdNoOnly stations at this outlet — id from get_outlets, not a store name

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare a safe read (readOnly/openWorld/destructive false), and the description adds substantial context beyond that: status is written by the client app, is best-effort, is lost while offline, and may be stale in either direction. It also discloses that the whole list returns in one plan-capped, non-paged call and that deleted stations are excluded.

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 purpose and the get_outlets/generic fallback immediately after; the status paragraph is long but every clause (offline loss, old app versions, stale-in-both-directions) changes how the agent should read the value. The four-synonym parenthetical is slightly padded but supports name matching.

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?

No output schema exists, yet the description covers what comes back (all stations, one call, no paging, deleted excluded) and what the flags mean, plus the cross-tool trust hierarchy. Nothing an agent needs to call and interpret this correctly 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; the description adds real meaning on top, notably that search matches the station NAME only and that outletId must come from get_outlets and is not a store name. It also surfaces the browser-till ('virtual') case that kind's enum encodes.

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 ('Every POS station ... the same list as Run → Stations') and enumerates synonyms (till, register, checkout lane, cash desk) so name-based routing works. It also explicitly disambiguates from siblings get_outlets and get_sessions rather than leaving that to inference.

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 explicit routing: don't call get_outlets to answer 'where is this till', call it only to convert a store name into an outletId; and never answer shift/money questions here — use get_sessions and get_session_report instead, with the tie-breaker rule that sessions win over the flag.

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

All Final POS – Custom POS Builder toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources