Warteg Online MCP Server

by andhikapraa

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between bulk_reschedule and reschedule_delivery, as both handle rescheduling with different granularities. Tools like get_available_addresses and get_my_restrictions are clearly separate, but the rescheduling functions could cause confusion if not carefully described.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., get_order_details, update_restrictions, hold_deliveries). The naming is predictable and readable throughout the set, with no deviations in style.
Tool Count5/5
With 15 tools, the server is well-scoped for managing package orders, deliveries, and dietary restrictions in a food delivery context. Each tool serves a specific function, such as authentication, retrieval, scheduling, and updates, without appearing excessive or insufficient.
Completeness4/5
The toolset covers core CRUD operations for orders, deliveries, addresses, and restrictions, including authentication. Minor gaps exist, such as no tool for creating new orders or deleting/cancelling deliveries, but agents can likely work around these with the available scheduling and update tools.
Average 3.3/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get all deliveries'), implying a read-only operation, but doesn't address permissions, rate limits, pagination, error handling, or what happens with invalid inputs. This leaves significant behavioral gaps for a tool with three required parameters.
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?
The description is efficiently structured with a clear purpose statement followed by parameter and return sections. Every sentence adds value, though the 'Args' and 'Returns' labels are slightly redundant with the schema but help readability. It's appropriately sized without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters, no annotations, and no output schema, the description does an adequate job explaining parameters and the return type. However, it lacks details on behavioral aspects like error conditions, data volume, or how results are structured, which are important given the tool's complexity and lack of structured metadata.
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?
The description adds meaningful context for all three parameters beyond the schema's 0% coverage: it explains that 'order_id' is for a package order, and specifies date formats and inclusivity for 'start_date' and 'end_date'. This compensates well for the schema's lack of descriptions, though it doesn't detail constraints like valid date ranges or order_id formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('deliveries'), specifying the scope ('within a specific date range'). However, it doesn't explicitly differentiate from sibling tools like 'get_delivery_summary' or 'get_order_details', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_delivery_summary' or 'get_order_details'. It also doesn't mention prerequisites, exclusions, or contextual factors, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a 'full delivery schedule' but does not cover critical aspects like authentication needs, rate limits, error handling, or whether it's read-only or has side effects. This leaves significant gaps in understanding the tool's behavior.
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?
The description is appropriately sized and front-loaded, with the main purpose stated first, followed by concise sections for arguments and returns. There is no wasted text, but the structure could be slightly improved by integrating the parameter explanation more seamlessly rather than as a separate 'Args' block.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It covers the basic purpose and parameter but misses behavioral details (e.g., authentication, errors) and output specifics (e.g., format of 'Formatted schedule'), which are crucial for a tool with no structured support.
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?
The description adds meaningful context for the single parameter 'order_id', explaining it as 'The ID of the package order', which clarifies its purpose beyond the schema's basic type (integer). With 0% schema description coverage, this compensation is effective, though it could be more detailed (e.g., format or source of the ID).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('full delivery schedule for an order'), making it immediately understandable. However, it does not explicitly differentiate from sibling tools like 'get_delivery_summary' or 'get_order_details', which might provide overlapping or related information, leaving some ambiguity about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings such as 'get_delivery_summary' and 'get_order_details', there is no indication of how this tool differs in context or when it should be preferred, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions authentication but lacks critical behavioral details: whether it returns a session token, sets cookies, has rate limits, requires specific permissions, or handles errors. The vague 'Success or failure message' return statement adds little value.
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?
The description is appropriately sized and front-loaded with the main purpose. The Args/Returns sections are structured but slightly verbose for a simple tool. Every sentence adds value, though the return statement could be more precise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (authentication is critical) and lack of annotations, the description is incomplete. It doesn't explain the authentication mechanism (e.g., token-based), session management, or error handling. The output schema exists but isn't detailed here, leaving gaps in understanding the tool's full behavior.
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 description coverage is 0%, but the description compensates by explaining both parameters: 'username: Your Warteg Online username' and 'password: Your Warteg Online password.' This adds clear meaning beyond the bare schema, though it doesn't cover format constraints (e.g., length, special characters).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Authenticate with the Warteg Online platform.' It specifies the verb (authenticate) and resource (platform), though it doesn't differentiate from siblings (none are authentication tools). However, it's not fully specific about what authentication entails (e.g., obtaining a session token).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., must be called before other tools), exclusions, or context for authentication. This is a basic gap for a critical authentication tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Change' implies a mutation operation, the description doesn't address critical behavioral aspects: whether this requires special permissions, if changes are reversible, what happens to existing deliveries, potential rate limits, or error conditions. The return statement mentions 'Summary of address changes' but provides no detail on format or content.
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?
The description is well-structured with clear sections (purpose, args, returns) and uses bullet points effectively. Every sentence earns its place by providing essential information. The only minor inefficiency is the repetition of date format (YYYY-MM-DD) for multiple parameters, but this is justified for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with 6 parameters, no annotations, and no output schema, the description is moderately complete. It excels at parameter documentation but lacks behavioral context about permissions, side effects, and return format. For a tool that modifies deliveries, more information about what 'change' entails and potential impacts would be valuable.
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?
The description provides excellent parameter semantics despite 0% schema description coverage. It clearly explains all 6 parameters with meaningful context: order_id identifies the package, new_address_id specifies the destination, date/start_date/end_date define temporal scope, and order_types enumerates valid values. This fully compensates for the schema's lack of descriptions, though it doesn't explain parameter interactions or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Change delivery address for specific deliveries.' This is a specific verb+resource combination that indicates a mutation operation. However, it doesn't explicitly differentiate this tool from sibling tools like 'bulk_reschedule' or 'reschedule_delivery' in terms of when to change address versus reschedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'bulk_reschedule', 'reschedule_delivery', and 'hold_deliveries', there's no indication of when address changes are appropriate versus other delivery modifications. No prerequisites, exclusions, or alternative recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns real-time or cached data, or handles errors. The description mentions what it returns but lacks operational context needed for safe invocation.
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?
The description is appropriately concise with three brief sentences that are front-loaded: purpose first, then parameter explanation, then return value. There's no wasted text, though the structure could be slightly improved by integrating the parameter and return sections more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter read operation) and lack of annotations/output schema, the description is minimally adequate. It covers purpose, parameter meaning, and return content, but misses behavioral aspects like authentication needs or error handling that would be important for completeness in this context.
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?
With 0% schema description coverage and only one parameter, the description effectively compensates by clearly explaining that 'order_id' refers to 'The ID of the package order'. This adds meaningful context beyond the schema's basic type information, making the parameter's purpose clear despite the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('summary of delivery statistics'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_order_details' or 'get_orders_by_date_range', which might also provide related delivery information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_order_details' and 'get_orders_by_date_range' available, there's no indication whether this tool is for aggregated statistics versus detailed information, or what specific context warrants its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions authentication requirement and return format, but doesn't cover important aspects like pagination behavior, rate limits, error conditions, or whether this is a read-only operation. For a tool with zero annotation coverage, this leaves significant gaps.
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?
The description is appropriately concise with two sentences that each serve clear purposes: stating the tool's function and describing the return value. There's no wasted text, though the structure could be slightly improved by combining related information more tightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return value documentation) and no parameters, the description covers the essential purpose and authentication context. However, for a tool with zero annotation coverage, it should provide more behavioral context about limitations, side effects, or usage patterns to be truly complete.
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?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description correctly doesn't waste space discussing non-existent parameters, earning a baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('package orders'), and specifies the scope ('for the authenticated user'). It doesn't explicitly differentiate from sibling tools like 'get_orders_by_date_range', but the scope limitation provides some implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_orders_by_date_range' or 'get_order_details'. It mentions the authenticated user scope but doesn't explain when this limitation matters or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('hold deliveries') and return type ('summary of held deliveries'). It lacks critical behavioral details: whether this is reversible, what permissions are needed, if it affects billing, error conditions, or rate limits. This is inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by organized parameter and return sections. Every sentence earns its place with no redundant information, making it highly efficient for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool with 4 parameters, the description is incomplete. It covers parameters well but misses behavioral context (e.g., side effects, error handling) and output details beyond a vague 'summary', leaving gaps for safe agent operation.
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 description coverage is 0%, so the description must compensate—it does so by explaining all 4 parameters with clear semantics: order_id identifies the package, hold_start/end define the date range, and order_types specifies meal types with examples. This adds significant value beyond the bare schema, though it doesn't cover format details like date validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Hold (pause)') and resource ('deliveries') with specific scope ('for a date range'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'skip_day' or 'reschedule_delivery' which might have overlapping functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'skip_day', 'reschedule_delivery', or 'bulk_reschedule'. It also doesn't mention prerequisites (e.g., authentication status) or contextual constraints, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return type ('List of available addresses with their IDs') but doesn't disclose behavioral traits such as authentication requirements, rate limits, error conditions, or whether this is a read-only operation. The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded. The first sentence states the purpose clearly, followed by structured Args and Returns sections. Every sentence earns its place with no redundant information, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no annotations, but with an output schema), the description is partially complete. It covers the purpose and parameter semantics adequately, and the output schema likely handles return values. However, it lacks usage guidelines and behavioral transparency, which are significant gaps for a tool in this context.
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?
The description adds meaning beyond the input schema by explaining the parameter's purpose: 'order_id: The ID of the package order.' Since schema description coverage is 0% (the schema only provides a title and type), this compensates well. However, it doesn't detail constraints like valid ID ranges or format, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get available delivery addresses for an order.' It specifies the verb ('Get'), resource ('available delivery addresses'), and context ('for an order'). However, it doesn't explicitly differentiate from sibling tools like 'get_order_details' or 'change_address', which might also involve address-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the order must be in a specific state), exclusions, or comparisons to siblings like 'get_available_restrictions' or 'change_address'. Usage is implied by the purpose but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It mentions the action ('reschedule') and a basic return ('Success or failure message'), but lacks details on permissions, side effects, error conditions, or system constraints like rate limits.
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?
The description is well-structured with a purpose statement followed by parameter and return sections. It's appropriately sized, though the 'Args' and 'Returns' labels are slightly redundant given the structured schema, but they don't detract significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage and no annotations, the description does well on parameters but lacks behavioral context. The output schema exists, so return values needn't be detailed, but overall it's adequate yet incomplete for a mutation tool with no safety disclosures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides clear semantics for all 5 parameters, including data formats (e.g., 'YYYY-MM-DD' for new_date) and allowed values for order_type ('LUNCH' or 'DINNER'), adding significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Reschedule') and resource ('a single delivery'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'bulk_reschedule' or 'skip_day', which would require mentioning it's for individual deliveries only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'bulk_reschedule' for multiple deliveries or 'skip_day' for skipping instead of rescheduling. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a mutation operation ('reschedule') but doesn't mention permission requirements, whether changes are reversible, potential side effects on other systems, rate limits, or what happens to deliveries outside the specified order_types. The return statement is minimal.
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?
The description is well-structured with a purpose statement followed by Args and Returns sections. Every sentence adds value, though the return statement could be slightly more informative. It's appropriately sized for a 5-parameter tool with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a bulk mutation tool with no annotations, the description is moderately complete. It covers parameter semantics well and mentions output existence, but lacks crucial behavioral context about permissions, reversibility, and system impacts. The presence of an output schema helps, but the description should provide more operational guidance for a potentially destructive action.
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 description coverage is 0%, so the description must compensate. It successfully explains all 5 parameters with clear semantics: order_id identifies the package, start_date/end_date define the range to reschedule, target_start_date specifies the new date, and order_types provides optional filtering. The format guidance (YYYY-MM-DD) and enum values for order_types add valuable context beyond the bare schema.
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?
The description clearly states the specific action ('bulk reschedule'), the target resource ('all deliveries within a date range'), and the transformation ('to new dates'). It uses precise verbs and distinguishes itself from the simpler 'reschedule_delivery' sibling tool by emphasizing bulk operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'reschedule_delivery' or 'hold_deliveries'. It mentions a date range scope but doesn't explain prerequisites, limitations, or appropriate contexts for bulk operations versus individual adjustments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format ('List of available restrictions grouped by category'), which is useful behavioral context. However, it doesn't mention other traits like whether this is a read-only operation, authentication needs, rate limits, or error handling. For a tool with zero annotation coverage, this is a minimal but adequate disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, and the second clarifies the return format. Every sentence earns its place with no wasted words, and the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is complete enough for basic use. It explains what the tool does and what it returns. However, without annotations or output schema, it could benefit from more detail on authentication or error cases, but the gaps are minor for this low-complexity tool.
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?
The tool has 0 parameters, and schema description coverage is 100% (though trivial here). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools. It appropriately focuses on output behavior instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all available dietary restrictions (pantangan) that can be set.' It specifies the verb ('Get') and resource ('dietary restrictions'), and the parenthetical 'pantangan' adds helpful context. However, it doesn't explicitly differentiate from sibling tools like 'get_my_restrictions' or 'update_restrictions', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_my_restrictions' (which likely retrieves user-specific restrictions) or 'update_restrictions' (which modifies them), leaving the agent to infer usage context. This lack of explicit when-to-use or alternative recommendations limits its utility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information (implying read-only), but doesn't mention authentication needs, rate limits, error conditions, or what 'detailed information' includes (e.g., order status, items, tracking). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the first sentence clearly states the purpose, followed by concise 'Args' and 'Returns' sections. Every sentence earns its place by providing necessary information without redundancy. It's appropriately sized for a simple retrieval tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) but lack of annotations and output schema, the description is minimally adequate. It covers the basic purpose and parameter semantics, but doesn't explain return values (e.g., what fields are included) or behavioral aspects like error handling. For a tool with no structured output definition, more detail on returns would improve completeness.
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?
The description adds meaningful context for the single parameter 'order_id', specifying it's 'The ID of the package order'. This clarifies the parameter's purpose beyond the schema's basic type (integer) and title ('Order Id'). With 0% schema description coverage, the description fully compensates by providing essential semantic information, though it doesn't detail format constraints (e.g., numeric range).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed information about a specific package order'). It distinguishes from siblings like 'get_orders_by_date_range' (which retrieves multiple orders) and 'get_package_orders' (which likely lists orders without details). However, it doesn't explicitly mention how it differs from 'get_delivery_summary' or 'get_schedule', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying it's for 'a specific package order' (singular), suggesting it should be used when you have an order ID. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'get_orders_by_date_range' for multiple orders or 'get_delivery_summary' for broader delivery info. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read operation ('Get') and specifies the return type ('List of the user's current dietary restrictions'), but does not disclose behavioral traits such as authentication needs, rate limits, or error handling. This is a minimal but adequate disclosure for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, and the second sentence explains the return value. Every sentence earns its place with no wasted words, making it highly concise and well-structured.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is complete enough for a basic read operation. It explains what the tool does and what it returns, though it could benefit from more behavioral context (e.g., authentication requirements) to reach a score of 5.
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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description does not add parameter semantics, but with no parameters, a baseline of 4 is appropriate as there is nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the current user's dietary restrictions (pantangan).' It uses a specific verb ('Get') and identifies the resource ('current user's dietary restrictions'), but does not explicitly differentiate it from sibling tools like 'get_available_restrictions' or 'update_restrictions', which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'current user's dietary restrictions,' suggesting it's for retrieving personal data rather than general or available restrictions. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_available_restrictions' or 'update_restrictions,' so it's only implied, not clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the core behavior (moving skipped deliveries to schedule end) and mentions the return format (summary). However, it lacks details on permissions needed, whether changes are reversible, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence adds value: the first explains the action, the parameter descriptions are essential, and the return statement is helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description covers the basic operation and parameters adequately. However, it lacks important context about side effects, authentication requirements, and what the 'summary' return contains.
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?
With 0% schema description coverage, the description fully compensates by explaining all 3 parameters: order_id identifies the package, skip_date specifies the date in YYYY-MM-DD format, and order_types clarifies the optional meal types. It adds meaning beyond the bare schema.
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?
The description clearly states the specific action ('skip deliveries'), the resource ('on a specific date'), and the mechanism ('by moving them to the end of the schedule'). It distinguishes from siblings like 'reschedule_delivery' or 'hold_deliveries' by specifying date-based skipping with schedule adjustment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for skipping deliveries on a date, but provides no explicit guidance on when to use this tool versus alternatives like 'reschedule_delivery' or 'hold_deliveries'. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a mutation operation ('Update') and shows how to clear restrictions, but doesn't mention authentication requirements, error conditions, side effects, or what 'Result of the update operation' actually contains.
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?
The description is well-structured with clear sections (purpose, args, available IDs, returns) and every sentence adds value. It could be slightly more concise by integrating the 'Available IDs' section more tightly with the parameter explanation, but overall it's efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description does well on parameter documentation but lacks important behavioral context. It doesn't explain what the return value contains, error handling, authentication needs, or side effects. The parameter coverage is excellent, but other aspects are incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must fully explain the parameter. It provides comprehensive documentation: the parameter name, format ('comma-separated list'), special values ('empty string or omit to clear'), and a detailed mapping of IDs to dietary restrictions across three categories (Protein, Additional, Rasa).
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?
The description clearly states the specific action ('Update') and resource ('user's dietary restrictions') with the local term 'pantangan' providing additional context. It distinguishes from sibling tools like 'get_my_restrictions' (read-only) and 'get_available_restrictions' (reference data).
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?
The description provides clear context for when to use this tool (to set or clear dietary restrictions) and implicitly distinguishes it from read-only siblings. However, it doesn't explicitly state when NOT to use it or mention alternatives like bulk operations or other user profile updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![wartegonline-mcp MCP server](https://glama.ai/mcp/servers/andhikapraa/wartegonline-mcp/badges/card.svg)](https://glama.ai/mcp/servers/andhikapraa/wartegonline-mcp)

Score Badge

Copy to your README.md:

[![wartegonline-mcp MCP server](https://glama.ai/mcp/servers/andhikapraa/wartegonline-mcp/badges/score.svg)](https://glama.ai/mcp/servers/andhikapraa/wartegonline-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/andhikapraa/wartegonline-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server