Order food from Cordering white-label restaurants: browse menus, confirm, then place an order.
Average 4.3/5 across 9 of 10 tools scored.
Each tool targets a distinct action and resource: order status vs. order staging vs. order placement, vendor discovery vs. menu retrieval, and login initiation vs. code submission. There is no overlap or ambiguity; even sequential tools like prepare_order and place_order are clearly separated by their purpose.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., check_order, list_vendors, prepare_order). Even the login and logout tools fit the pattern as single verbs, and there is no mixing of conventions.
With 10 tools, the surface is well-scoped for a restaurant ordering domain. It covers discovery, menu browsing, account management, login flow, order staging, placement, and status checking without feeling bloated or too thin.
The core ordering lifecycle is covered end-to-end (vendor -> menu -> login -> prepare -> place -> check). The only noticeable gaps are the absence of an explicit address-saving tool (though referenced in the login description) and no order cancellation or update capability, though these may be out of scope for typical ordering workflows.
check_orderAInspectCheck the current status of an order the user has already placed, using the order number returned by place_order. Reports whether the restaurant has accepted it, whether it is on its way, and whether it has finished (delivered or declined). There is no background tracking and no notification: call this again when the user asks, and only until the order is reported as finished.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | The order number returned by place_order. | |
| clientId | No | clientId of the restaurant the order was placed with, from the list_vendors result. Omit only when the server is configured for a single restaurant. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on disclosure duty and does so well: it states there is no background tracking, no notification, and that repeated calls are required until a terminal status. This goes beyond the schema and prevents the agent from assuming push updates or caching.
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?
Three compact sentences front-load the core action, then add return semantics and polling behavior. No filler or repeated schema content beyond a useful reminder of the order-number source.
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 a simple two-parameter tool with no output schema, the description covers the needed lifecycle: when to call, what statuses are reported, and when to stop. Minor omissions like error/not-found behavior are not critical for selecting and invoking this 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?
Schema already documents both parameters at 100% coverage, including the orderId source and the clientId/restaurant-single-restaurant rule. The description adds little beyond restating the orderId origin, so it meets the baseline but does not elevate it.
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 clear verb ('Check') and resource ('current status of an order'), and differentiates from siblings by specifying it is for orders already placed via place_order, not for preparing or placing orders. The description enumerates what it reports (accepted, on way, finished), leaving no ambiguity.
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 explicit usage context: it is for orders already placed, uses the orderId returned by place_order, and should be polled only when the user asks and only until finished. It does not name sibling alternatives directly, but the placement-vs-status distinction is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_accountsAInspectShow which accounts are signed in, per restaurant, and which one is active. Useful when the user keeps separate work and personal accounts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. 'Show' implies a read-only operation, and the description states what information is surfaced (signed-in accounts, active account, per restaurant). It does not explicitly confirm absence of side effects or mention any authentication assumptions, but for a simple list operation this is reasonably transparent.
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?
Two concise sentences with no filler. The main action and scope are front-loaded, followed by a briefly stated practical use case. Every sentence 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?
For a zero-parameter list tool, the description fully conveys the tool's purpose and likely output. It doesn't detail the exact return format, but no output schema exists and the description sufficiently explains what the agent can expect. The sibling context makes the tool's role even clearer.
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 zero parameters and the schema is empty, so the baseline is 4. The description adds context about what the output covers, which is helpful, and no parameter documentation 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?
The description uses a specific verb ('Show') and resource ('which accounts are signed in, per restaurant, and which one is active'), clearly distinguishing it from sibling tools like login, logout, and switch_account that perform actions rather than list state.
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?
It gives a clear usage context: 'Useful when the user keeps separate work and personal accounts.' It does not explicitly say when not to use it or name alternative tools, but the context is enough for an agent to know when this listing tool fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_vendorsAInspectFind restaurants (vendors) available for ordering. This is the discovery entry point: each card shows the clientId and vendorId that list_menu and prepare_order need. Call it with no arguments to list every restaurant — that is the normal case. Returns a complete, self-contained HTML document of vendor cards (logo, address, phone, delivery fee) — restaurants open today first in colour, those closed today greyed out at the bottom. Present the returned HTML to the user by opening it as an HTML artifact; do not paste the markup into the chat.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City to filter by. Pass this ONLY when the user named a city themselves; never guess one from context, because a filter that matches nothing hides restaurants the user could have ordered from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: it discloses the return format (complete self-contained HTML document), the card contents (logo, address, phone, delivery fee), ordering behavior (open today first, closed greyed out at bottom), and presentation instructions. This goes well beyond the schema.
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?
Every sentence earns its place: purpose, entry-point role, normal call pattern, return format, visual ordering, and output handling. It is front-loaded with the most important information and contains no filler, tautology, or redundant restatement of the tool name.
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?
Despite no output schema and no annotations, the description fully covers what an agent needs: when to call, what arguments are safe, what the result looks like, how to render it, and how it connects to downstream tools like list_menu and prepare_order. Nothing essential 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?
Schema coverage is 100%, but the description adds critical meaning to the single parameter: city should be passed only when explicitly named by the user, and never guessed, because an empty filter result would hide valid restaurants. This is valuable operational guidance not present in the schema.
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 states a specific verb and resource ('Find restaurants (vendors) available for ordering') and immediately positions it as the discovery entry point. It explains the output's role — providing clientId and vendorId needed by list_menu and prepare_order — which clearly differentiates it from sibling tools.
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?
It gives explicit guidance: call with no arguments as the normal case, pass city only when the user names one, and never guess a city from context. It also tells the agent how to present the output (HTML artifact, not pasted markup), which is essential for correct downstream behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
loginAInspectStart signing the user in to a restaurant so they can place orders. Browsing the menu never needs this — only ordering and saving an address do. Returns a URL the user must open in a browser to sign in with Google or Apple; afterwards they copy the 'code' value from the address bar and you call submit_login_code. Each restaurant has its own login, so this must be done per restaurant.
| Name | Required | Description | Default |
|---|---|---|---|
| clientId | No | clientId of the restaurant to sign in to, from a list_vendors result. Omit only when the server is configured for a single restaurant. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It explains the two-step browser flow, that a URL is returned, that the user must open it, and that a code must be copied and passed to submit_login_code. It stops short of describing session/expiry behavior or potential errors, so it is not a 5, but it is substantially transparent.
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?
Three sentences, each earning its place: the purpose, when it is and is not needed, and the exact multi-step protocol. The most important scoping constraints are front-loaded, and there is no filler.
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 multi-step authentication flow with no output schema, the description explains the returned URL, the external browser interaction, the code extraction, the next sibling to call, and the per-restaurant constraint. Minor gaps remain around expiration, errors, and what happens on repeated calls, but an agent has enough to invoke it 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?
The schema already documents clientId with meaningful context, and the description does not add parameter-specific detail. However, the description's per-restaurant note reinforces why clientId matters. With 100% schema coverage, baseline 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 action ('Start signing the user in'), the resource (a restaurant), and the overall goal (place orders). Clearly distinguishes itself from the sibling submit_login_code by positioning this as the first step that returns a URL, and notes that browsing the menu never requires it.
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?
Explicitly says when login is needed ('only ordering and saving an address do'), when it is not needed ('Browsing the menu never needs this'), and gives the follow-up step ('you call submit_login_code'). It also warns that login is per restaurant, which prevents a common misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
logoutAInspectSign the user out. By default signs out of every restaurant; pass a clientId to sign out of one, and an account label to sign out just that account.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Account label to sign out, e.g. 'work'. Omit to sign out every account at that restaurant. | |
| clientId | No | clientId of the restaurant to sign out of. Omit to sign out everywhere. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the main action and the scope nuances, but it does not mention side effects such as token/session invalidation, whether the action can be undone, or whether an active session is required. That is a moderate gap for a no-annotation tool, though the described behavior is still basic and understandable.
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, front-loaded sentence that states the purpose first and then lists the scope options in order of increasing specificity. Every clause earns its place, and there is no redundant filler.
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 logout with only two optional parameters, the description is largely complete: it explains defaults and scoping, and the input schema covers parameter formats. It does not need to explain return values for a logout action, though an explicit note about session invalidation or irreversibility would make it fully complete given the absence of annotations.
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?
Schema description coverage is 100%, so the schema already documents both parameters and their defaults. The description restates that information in prose and adds the 'every restaurant' default, but it does not meaningfully clarify the ambiguous combined case of passing both clientId and label. Since the schema handles the heavy lifting, baseline 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 opens with the specific verb and resource ('Sign the user out') and then distinguishes the three scopes: all restaurants, one restaurant via clientId, and one account via label. This clearly separates logout from siblings like login, switch_account, and check_order, so an agent knows exactly what this tool does.
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 explains the default behavior and the exact parameter-based conditions for narrowing the scope: omit all params for global logout, pass clientId for a restaurant, pass a label for a single account. It does not explicitly name alternatives like switch_account or state when not to use logout, but the intended usage is clear from the action and the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
place_orderAInspectPlace an order previously staged by prepare_order. Requires the confirmationToken returned by prepare_order. This causes a real order to be sent to the vendor.
| Name | Required | Description | Default |
|---|---|---|---|
| confirmationToken | Yes | The confirmationToken returned by prepare_order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It explicitly discloses the key side effect: 'This causes a real order to be sent to the vendor,' signaling that this is a consequential, irreversible action. It does not cover auth or failure behavior, but the most important operational trait is stated.
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?
Three short sentences, each earning its place: the action, the required parameter, and the real-world consequence. Information is front-loaded and there is no redundant wording.
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 one-parameter, no-output-schema tool, this description covers the essential context: what the tool does, what is required, and the consequential side effect. It could mention what happens on invalid tokens or whether the operation is idempotent, but these are not necessary for correct invocation.
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?
Schema description coverage is 100% and the parameter's schema description already states it is the confirmationToken returned by prepare_order. The tool description reinforces this but does not add significant new semantic detail beyond the structured schema.
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 a specific action ('Place an order') and distinguishes it from preparation via 'previously staged by prepare_order.' It is not a tautology and clearly separates concern from sibling tools such as prepare_order or check_order.
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 explains the prerequisite: the order must already be staged by prepare_order and requires the confirmationToken returned by that tool. It gives a clear usage context, though it does not explicitly list when not to use this tool or name alternative tools for exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prepare_orderAInspectResolve a natural-language food order (one or more items) to concrete menu items and return a summary plus a confirmation token. Does NOT place the order. Call place_order with the returned token to actually place it.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Delivery date-time as an ISO-8601 UTC instant, e.g. '2026-07-25T12:00:00Z'. Must be in the future. Defaults to 5 minutes from now (as soon as possible) — only pass this when the user asks for a specific time. | |
| items | Yes | The item(s) to order — one or more lines, each with an item name, an optional quantity (default 1), an optional size, and optional extra ingredients by name. | |
| notes | No | Optional notes for the vendor. | |
| cutlery | No | Whether to ask the restaurant to include disposable cutlery. Only pass this when the user says either way; omit to leave it to the restaurant's default. Ignored (with a note) by vendors that do not offer it. | |
| clientId | No | clientId of the restaurant, from a list_vendors result. Omit only when the server is configured for a single restaurant. | |
| vendorId | No | vendorId of the restaurant, from a list_vendors result. Omit only when the server is configured for a single restaurant. | |
| bringTerminal | No | Whether the courier should bring a card terminal so the order can be paid by card on delivery. Pass true when the user wants to pay by card, false for cash; omit when they do not say. Ignored (with a note) by vendors that cannot take card on delivery. | |
| deliveryAddress | Yes | Delivery address text, e.g. 'Orlovica Pavla 26'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the burden of behavioral disclosure. It explicitly states the operation does not place the order, which signals this is a non-committal preparation step, and describes the return as summary + token. This is strong but not exhaustive—auth requirements and token validity are not mentioned.
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?
Two tight sentences with the core purpose and the critical non-side-effect front-loaded, followed by routing info. No filler.
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 tool with 8 parameters but a fully documented schema and no output schema, the description supplies the essential missing context: what the tool does, what it returns, and that it doesn't place the order. The only minor gap is auth requirements, but the overall description is complete enough for correct invocation.
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?
Schema description coverage is 100% and every parameter (items, deliveryAddress, date, notes, cutlery, clientId, vendorId, bringTerminal) is documented in the schema itself. The tool description adds no additional parameter-level meaning, so it sits at the baseline of 3.
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 action ('resolve ... to concrete menu items') with a clear resource (food order) and output (summary + confirmation token). Explicitly distinguishes itself from place_order by stating it does NOT place the order, so an agent can immediately tell them apart.
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?
Directs the agent to call place_order with the returned confirmation token when the user wants the order actually placed, and explicitly states this tool does not place orders. This is a clear exclusion and routing to the correct sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_login_codeAInspectComplete a sign-in started by login, using the 'code' value the user copied from the browser address bar. On success the user can place orders from that restaurant.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The code value copied from the redirect URL after signing in. | |
| label | No | Optional label for this account, e.g. 'work' or 'personal'. Defaults to the email address on the account. | |
| clientId | No | clientId of the restaurant being signed in to. Omit if only one sign-in is in progress. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does state the main effect (completes sign-in, enables order placement) and the input source (browser address bar), but it does not mention potential side effects, session state changes, or error conditions such as invalid or expired codes.
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?
Two sentences, no filler. The description front-loads the purpose, then states the input source and the success outcome. Every sentence contributes useful 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?
For a simple tool with three parameters and schema coverage of 100%, the description provides the key workflow context: it follows login, uses a browser-copied code, and enables ordering from that restaurant. It does not describe the return value or all possible failure modes, but these are somewhat outside the core description burden given the simple schema.
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?
Schema description coverage is 100%, so the schema already documents all three parameters. The description reinforces the meaning of 'code' but adds no additional semantics for 'label' or 'clientId' beyond what the schema provides.
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 completes a sign-in started by login, using a code from the browser address bar. It also distinguishes this from the login step by naming 'login' as the starting point, and clarifies the outcome (ability to place orders from that restaurant).
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 gives clear context: use this after login has started and the user has copied a code from the browser address bar. It implicitly contrasts with login by saying 'started by login,' but it does not explicitly list when-not-to-use or mention alternatives like switch_account.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
switch_accountAInspectChoose which signed-in account to order with at a restaurant, e.g. to switch between work and personal. The account must already be signed in via login.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Account label to make active, e.g. 'work'. | |
| clientId | No | clientId of the restaurant. Omit only when the server is configured for a single restaurant. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It communicates that the tool changes which signed-in account is active for ordering and that the account must already exist. However, it does not disclose what happens when the label is invalid, whether the switch is persistent, or what the return response is, so transparency is only partial.
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 two short sentences with no filler. The core action and prerequisite are front-loaded, and every clause contributes to correct tool usage.
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 state-selection tool with two well-documented parameters and no output schema, the description covers the essential behavior and prerequisite. It does not explain error behavior or how the switch affects subsequent order calls, but the context provided is adequate for correct invocation in most cases.
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?
Schema description coverage is 100%, so the schema already documents both parameters including the 'work' label example. The description adds the work/personal context and the restaurant-scoped ordering intent, but it does not meaningfully extend the parameter semantics beyond the schema.
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 uses a specific verb ('Choose') and a clear resource (which signed-in account to order with), with a concrete example (work vs personal). It also distinguishes itself from login/logout by explicitly requiring the account to already be signed in.
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 clearly states the prerequisite condition: the account must already be signed in via login. This implicitly tells the agent not to use this tool before login and suggests login as the alternative when the account is not yet signed in. It does not explicitly mention using list_accounts to discover valid labels, but the condition is still actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Discover Servd venues, browse menus, validate carts, place confirmed orders, and track status.
AI food ordering across Canada — 17,000+ restaurants, 89 cities, real UberEats + DoorDash.
Run your restaurant from an AI client: orders, menu, reports, refunds, payouts and staff.
AI-native restaurant discovery: verified/menu-indexed/discovered tiers + signed allergy-safety data.
