Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Toast MCP Server show me today's sales summary"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An unofficial, read-only Model Context Protocol server for exploring Toast restaurant operations. It runs immediately with realistic synthetic data, provides a modern MCP App dashboard, and can use customer-supplied Toast credentials when they are available.
Current status: public beta. Demo behavior and official API contracts are verified. Live Toast behavior is not maintainer-verified because this project does not yet have Toast sandbox or production access. The server reports that boundary in every tool response instead of presenting contract coverage as live certification.
This repository is not affiliated with or endorsed by Toast, Inc. Toast is a trademark of its respective owner.
The original repository advertised dozens of write tools against API shapes that no longer matched Toast's published contracts. Community Edition 2 preserves that work in legacy/v1 and replaces the active server with a smaller, supportable foundation:
safe demo mode with no account or credentials required;
eight focused, read-only MCP tools;
privacy-minimized order output with guest and card data excluded;
an interactive MCP App operations overview;
current MCP server and app SDKs with structured tool output;
configurable Toast-provisioned access URLs and current machine-client authentication;
token reuse, endpoint pacing, retry handling, and Retry-After support;
a pinned catalog of all 17 current Toast-hosted public API families;
weekly automated drift checks against Toast's official OpenAPI files.
Related MCP server: CraveUp MCP Server
Requirements: Node.js 20 or newer.
git clone https://github.com/BusyBee3333/toast-mcp-2026-complete.git
cd toast-mcp-2026-complete
npm ci
npm run buildDemo mode is the default:
npm startTo connect a desktop MCP client, point it at the built entry point. Replace the path below with the absolute path to your clone:
{
"mcpServers": {
"toast-community": {
"command": "node",
"args": ["/absolute/path/to/toast-mcp-2026-complete/dist/src/main.js"],
"env": {
"TOAST_MCP_MODE": "demo"
}
}
}
}For local Streamable HTTP transport:
TOAST_MCP_TRANSPORT=http npm start
curl http://127.0.0.1:3000/healthThe MCP endpoint is http://127.0.0.1:3000/mcp. HTTP binds to loopback by default.
Tool | Purpose |
| States whether data is synthetic or live and what has actually been verified. |
| Lists all current Toast-hosted API families and their implementation status. |
| Lists the explicitly configured restaurant locations. |
| Returns privacy-minimized orders for an ISO 8601 range of up to 31 days. |
| Gets a privacy-minimized order summary by Toast GUID. |
| Searches resolved Menus V2 items, groups, names, PLUs, and SKUs. |
| Reads current Stock API inventory risks and preserves unknown status values. |
| Returns metrics and an interactive MCP App operations dashboard. |
Every successful tool returns both structuredContent and a text fallback. Each payload includes:
dataSource: demo or live;
verificationState: demo_verified or contract_verified_live_unverified;
generatedAt: an ISO 8601 timestamp.
Toast does not publish one universal production or sandbox hostname. Toast provisions an API Access URL and credentials for an approved integration or eligible customer account. Do not infer or hard-code an unofficial hostname.
export TOAST_MCP_MODE=live
export TOAST_API_ACCESS_URL="https://your-toast-provisioned-access-url"
export TOAST_CLIENT_ID="..."
export TOAST_CLIENT_SECRET="..."
export TOAST_RESTAURANT_GUIDS="location-guid-1,location-guid-2"
npm startThe server sends the current login request to:
{TOAST_API_ACCESS_URL}/authentication/v1/authentication/loginIt reads token.accessToken and token.expiresIn, shares one cached token across configured locations, refreshes it with single-flight protection, and sends Toast-Restaurant-External-ID on location-scoped calls.
Live HTTP mode is intentionally restricted to loopback until the project has an inbound MCP authorization design. Credentials are read from environment variables, are never returned to the model, and should be supplied through your own secret manager in production.
Standard API access: self-service, production-only, read-only, and limited to eligible restaurant accounts. Standard access uses Menus V2, not Menus V3.
Partner or custom integration: Toast-provisioned scopes, sandbox access, certification, and production approval.
Analytics API access: separate credentials and eligibility. It is not assumed to share the operational API account.
Customers should run live mode inside infrastructure they control. The maintainer does not need to collect customer client secrets to demonstrate or support this project.
The catalog below was checked against Toast's official OpenAPI responses on August 28, 2026. Versions are info.version values, which are separate from URL versions.
API family | Base path | Spec | Community Edition status |
Authentication |
| 1.0.0 | Implemented infrastructure |
Orders |
| 2.9.5 | Implemented read subset |
Menus V2 |
| 2.4.1 | Implemented read subset |
Restaurants |
| 1.0.0 | Implemented read subset |
Stock |
| 1.0.0 | Implemented read subset |
Partners |
| 1.0.2 | Catalog only; scope-aware discovery is next |
Analytics |
| 1.0.0 | Catalog only; requires separate access |
Cash Management |
| 1.1.0 | Catalog only |
Configuration |
| 2.5.0 | Catalog only |
Credit Cards |
| 1.0.0 | Catalog only; partner write surface |
Device Details |
| 1.0.0 | Catalog only |
Kitchen |
| 1.0.2 | Catalog only |
Labor |
| 1.9.0 | Catalog only |
Menus V3 |
| 3.4.1 | Catalog only; ordering partners only |
Order Management Configuration |
| 1.0.1 | Catalog only |
Packaging |
| 1.0.0 | Catalog only |
Restaurant Availability |
| 1.0.1 | Catalog only |
catalog only means the official contract is tracked and drift-checked; it does not mean the API has an exposed MCP tool or has been tested with live Toast data.
Menus V3 is not a blanket replacement for Menus V2. Toast directs ordering partners to V3, while non-ordering and Standard API integrations should continue using V2. The server will only activate V3 for the appropriate integration type and granted scope.
Toast's gift card, loyalty, and tender specifications are outbound integration contracts hosted by the integrator. They are not Toast-hosted REST APIs that this MCP can simply call, so they are intentionally excluded from the 17-family count.
Toast's public developer update feed currently lists one August 2026 API change: on August 11, Analytics guest-payment results added cardLast4Digits, cardType, and paymentAccountReference. This server catalogs Analytics but does not expose guest-payment reporting because it requires separate access and includes sensitive payment-related data.
Other recently introduced surfaces are still included: Device Details became generally available July 7, and Kitchen item-fulfillment export was announced June 30. The manifest tracks the complete current reference surface rather than only entries dated in August.
Toast changed its compatibility policy on July 20, 2026 so adding enum values is no longer considered breaking. Live response normalization therefore preserves unknown fields and enum values instead of rejecting them.
All active tools are read-only and declare MCP read-only annotations.
Order summaries exclude guest identity, contact, delivery, and payment-card fields.
No customer or card data is stored by this server.
Synthetic demo records are visibly labeled and cannot be confused with a live restaurant.
Toast request IDs are retained in normalized errors for support, but credentials are not logged.
Only safe GET requests are retried; write APIs are not exposed.
Host and Origin validation protect local HTTP mode from basic DNS-rebinding and cross-origin requests.
Public live HTTP deployment is refused until inbound MCP authentication is configured.
See SECURITY.md for reporting and deployment guidance.
npm run typecheck
npm test
npm run build
npm run contract:check
npm run package:checkThe pinned manifest is contracts/toast-api-manifest.json. A scheduled GitHub workflow downloads each official specification, checks its version and SHA-256 hash, and opens an actionable failure when Toast changes a contract. Hash changes are never accepted automatically.
The official specifications mix Swagger 2.0 with OpenAPI 3.0.x. Packaging is OpenAPI 3.0.3 and Stock is OpenAPI 3.0.1; the remainder are currently Swagger 2.0. Future code generation must normalize those dialects rather than assuming one schema format.
No amount of public-contract work can replace these gates:
validate authentication, response shapes, pagination headers, and rate-limit headers in Toast sandbox;
confirm exact scopes returned for real connected restaurants;
certify Menus V3 behavior with an ordering-partner account;
validate Analytics job creation, polling, and seven-day report expiry with separate credentials;
exercise webhooks, signature verification, retry behavior, and large payload handling;
pass Toast's partner review, security review, certification, and production approval where applicable.
Until those gates are completed, the accurate release label is contract-verified and live-unverified.
See CONTRIBUTING.md. The most valuable contribution is live validation from someone with legitimate Toast sandbox or production access who can share redacted behavior, never credentials or restaurant data.
When proposing a new tool, include the official operation, required scope, integration type, pagination behavior, rate limit, PII classification, demo fixture, tests, and read/write risk. Write tools will require a separate approval and audit design.
MIT. See LICENSE.
Returns privacy-minimized order summaries for an ISO 8601 time range of at most 31 days.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| endDate | No | ISO 8601 timestamp; defaults to now. | |
| startDate | No | ISO 8601 timestamp; defaults to 24 hours ago. | |
| restaurantGuid | No | Toast restaurant GUID. Defaults to the first configured location. |
| Name | Required | Description |
|---|---|---|
| orders | Yes | |
| context | Yes | |
| endDate | Yes | |
| startDate | Yes | |
| restaurantGuid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context by disclosing that results are privacy-minimized summaries rather than full orders and by capping the query window at 31 days, which is not inferable from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the return type and then stating the key constraints. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering safety, this is functionally complete for a simple list query. It does not explicitly route to toast_get_order for full single-order details, but that gap is more about usage guidance than missing invocation information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents startDate, endDate, restaurantGuid, and limit constraints, so the baseline is 3. The description supplements this by clarifying that startDate and endDate form a range and by adding a 31-day maximum window that is not present in the individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific result type (privacy-minimized order summaries) and constrains the query to an ISO 8601 time range of at most 31 days. This clearly communicates a batch summaries operation rather than a single-order fetch, though it does not explicitly name or differentiate siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The time-range constraint implies when to use this tool: when order summaries over a date window are needed. However, there is no explicit guidance about when not to use it or to prefer a sibling like toast_get_order for full order details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every current Toast-hosted public API family and distinguishes implemented read coverage from catalog-only APIs that require Toast access and validation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| source | Yes | |
| context | Yes | |
| checkedAt | Yes | |
| apiFamilies | Yes | |
| totalApiFamilies | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds a behavioral nuance by clarifying that it distinguishes implemented read coverage from catalog-only APIs, implying that some API families are not yet implemented and may require further access or validation. This goes slightly beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the tool's exact purpose without any filler. It is well-structured, front-loading the core action and then providing the useful distinction. No unnecessary words or redundant information are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters and no output schema, the description adequately conveys what the tool returns. It explains that it lists all API families and distinguishes two categories. It does not specify the exact output format or whether pagination is involved, but given the intended purpose as a coverage overview, the description is complete enough for an agent to understand the tool's capability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema reflects this with an empty properties object. There is no parameter information to explain, so the description does not need to add meaning. The description still provides context about the tool's output, but since there are no parameters, this dimension is trivially satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it lists every current Toast-hosted public API family and distinguishes implemented read coverage from catalog-only APIs. The verb 'Lists' and the specific resource 'API family' make the purpose unambiguous, and the distinction between read coverage and catalog-only APIs adds useful precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While the purpose implies it is for getting an overview of API coverage, it does not mention any sibling tools or conditions under which this tool is preferred. The lack of comparative usage guidance leaves the agent to infer appropriateness from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads Toast Stock API inventory. Live responses normally contain OUT_OF_STOCK and QUANTITY items only.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Optional current or future Toast stock status. Unknown values are preserved. | |
| restaurantGuid | No | Toast restaurant GUID. Defaults to the first configured location. |
| Name | Required | Description |
|---|---|---|
| context | Yes | |
| inventory | Yes | |
| restaurantGuid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds a minor detail about live responses but does not significantly expand on side effects, data freshness, or other behavioral aspects. It is consistent with the annotations, so the score is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant or extraneous information. It is efficiently structured and immediately conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter tool with comprehensive annotations and parameter schema, the description is largely complete. The note about typical response content provides useful context. It does not describe the output format or any filtering behavior, but these are not critical for understanding the tool's basic function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for both parameters (status and restaurantGuid) are provided, covering 100% of the parameters. The description does not add further semantic detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads Toast Stock API inventory, specifying the resource and action. It also notes the typical response content (OUT_OF_STOCK and QUANTITY items), which adds context. However, it doesn't explicitly distinguish itself from sibling tools, though the names themselves provide some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. There is no mention of use cases, limitations, or comparisons to sibling tools. The note about live responses is implicit but not actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets one order by Toast GUID, excluding customer identity, contact, delivery, and payment-card fields.
| Name | Required | Description | Default |
|---|---|---|---|
| orderGuid | Yes | Toast order GUID. | |
| restaurantGuid | No | Toast restaurant GUID. Defaults to the first configured location. |
| Name | Required | Description |
|---|---|---|
| order | Yes | |
| context | Yes | |
| restaurantGuid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although the annotations already indicate read-only, idempotent, and non-destructive behavior, the description adds meaningful transparency by explicitly stating that customer identity, contact, delivery, and payment-card fields are excluded from the response. This clarifies the scope of returned data beyond the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that concisely conveys the primary action and the key exclusion. There is no redundant or extraneous information, making it well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID operation, the description covers what it does and what it returns (with exclusions). Since the tool has an output schema, the description does not need to explain return values, and no other critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (orderGuid as 'Toast order GUID' and restaurantGuid with default behavior), giving 100% coverage. The description text itself does not add additional meaning to the parameters beyond referencing the GUID in the action, so it remains at the baseline for schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (gets one order), the resource (order), and the identifier (Toast GUID). It also distinguishes itself from sibling tools like find_orders by indicating it retrieves a single order by GUID rather than searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you have a specific Toast order GUID and need a single order. It also implicitly warns against use when customer identity, contact, delivery, or payment-card fields are needed, as these are excluded. However, it does not explicitly name alternative tools like find_orders for search scenarios, so it falls slightly short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explains whether this server is using safe demo data or customer-supplied live Toast credentials, and what has been verified.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| safety | Yes | |
| context | Yes | |
| contractBaseline | Yes | |
| readyForLiveData | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds context about what is checked (demo vs live credentials) and aligns with the annotations. No contradiction, and the extra detail goes beyond the basic annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is direct and free of fluff. The description front-loads the core purpose and includes enough detail without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and a declared output schema, the description adequately explains the tool's function. It states what is determined (demo vs live) and what is covered (what has been verified), making it complete for a no-input status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters and schema coverage is 100%, so the baseline is 3. The description does not need to explain parameters, and it adds no misleading information. Given the absence of parameters, the description effectively covers the semantic space.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool explains whether the server uses demo data or live credentials and what has been verified. The verb 'explains' and specific subject make the purpose unambiguous, and it is easily distinguished from sibling tools that handle data operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The intended use is implied by it being a status/verification tool, but the description does not mention when a user should prefer it over other tools or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the demo restaurant or the explicitly configured live Toast restaurant locations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| context | Yes | |
| locations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context about the demo/live scope, which helps set expectations without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no filler. The key information (what it lists and the demo/live distinction) is presented efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the operation and the presence of an output schema, the description fully covers what an agent needs to know. The demo/live context is sufficient for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so there is nothing to explain. The empty schema is fully covered by the description's implicit statement that no input is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific action (Lists) and resource (restaurant locations), and clarifies the distinction between demo and live configurations. Clearly differentiates from sibling tools by scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit guidance on when to use this tool over alternatives. The demo vs live distinction is implicit but no direct comparison to siblings like toast_get_verification_status or toast_find_orders is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Builds a privacy-safe sales and inventory overview and renders an interactive MCP App when supported.
| Name | Required | Description | Default |
|---|---|---|---|
| endDate | No | ISO 8601 timestamp; defaults to now. | |
| startDate | No | ISO 8601 timestamp; defaults to 24 hours ago. | |
| restaurantGuid | No | Toast restaurant GUID. Defaults to the first configured location. |
| Name | Required | Description |
|---|---|---|
| context | Yes | |
| overview | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, openWorld, and non-destructive behavior. The description adds context about 'privacy-safe' handling and conditional rendering of an interactive app, which clarifies behavior beyond the annotation defaults. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that covers purpose, key behavior, and conditional output. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema is present, so return value explanation is unnecessary. The description gives enough context about what the tool does and when it renders an app, but does not detail edge cases like unsupported app environments. Overall sufficient for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are described with defaults, achieving 100% schema coverage. The description does not add additional meaning beyond the schema, but the schema itself is sufficient for basic understanding. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Builds') with a clear resource ('operations overview') and outcome (sales and inventory overview, rendering an interactive MCP App). Distinguishes from siblings by offering a consolidated overview rather than raw data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when a high-level overview of sales and inventory is needed, but does not explicitly state when to prefer this over sibling tools like toast_get_inventory or toast_find_orders. Lacks explicit prerequisites or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.0-beta.1toast_find_orderstoast_get_api_coveragetoast_get_inventorytoast_get_ordertoast_get_verification_statustoast_list_locationstoast_search_menutoast_show_operations_overviewScored across 8 tools
Each tool targets a distinct resource or meta-information area, so confusion is unlikely. Minor overlap exists between find_orders and get_order (plural vs singular) and between get_inventory and show_operations_overview, but descriptions clarify scope.
All tools use the consistent 'toast_' prefix and mostly follow verb_noun naming (get_, list_, find_, search_). 'show_operations_overview' slightly breaks the verb pattern but remains intuitive and aligned with the others.
Eight tools is well within the optimal range and appropriately scoped for a focused Toast POS read-oriented MCP server. Each tool adds meaningful functionality without unnecessary redundancy.
The set covers core read operations for locations, orders, menu, inventory, and an overview, which is reasonable for a privacy-safe server. However, it lacks write/update operations and many Toast API families beyond the ones listed, leaving the surface notably incomplete for full Toast platform coverage.
Run your restaurant from an AI client: orders, menu, reports, refunds, payouts and staff.
Give your AI agents the tools to build, manage, and run automation workflows.
Connect AI agents to 1000+ apps with managed authentication and tool-calling.
One place to build, share, and govern the skills and tools your AI agents use at work.
