crowntowncompost-mcp

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation5/5
Each tool targets a distinct resource or action: account read/update, authentication check, dashboard summary, past services, upcoming services, skipping, invoices, missed pickup reporting, and support contact. There is no meaningful overlap between any two tools, and the descriptions explicitly note differences (e.g., read-only vs. update, past vs. upcoming).
Naming Consistency4/5
All tools use a consistent crowntown_ prefix and snake_case, with most following a verb_noun pattern (get_account, update_account, list_service_history, skip_service, etc.). The only minor deviation is crowntown_healthcheck, which uses a noun rather than a verb, but it is still clear and fits the overall naming scheme.
Tool Count5/5
With 10 tools, the server is well-scoped for a customer-facing compost service portal. Each tool addresses a distinct customer need without redundancy, fitting comfortably within the ideal 3–15 tool range.
Completeness4/5
The tool surface covers the core customer lifecycle: account management, schedule viewing/skipping, service history, invoices, and support. Minor gaps exist—for example, no explicit way to change service address or subscription plan—but the provided tools handle the most common workflows without dead ends.
Average 4.4/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on August 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the critical dry-run behavior: without confirm:true, the tool returns a preview and makes no network call. This adds valuable context beyond the readOnlyHint=false annotation, which indicates mutation potential. The annotation and description are consistent.
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 two sentences long, front-loaded with the main action, and contains no filler. Every sentence adds value.
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?
For a simple action tool with rich schema annotations and no output schema, the description is largely complete. It covers the key behavioral nuance (dry run vs. actual send) that an agent needs to know before invoking. It could potentially mention when to use this over sibling tools, but the absence is not critical given the tool's straightforward purpose.
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 input schema already covers all four parameters with detailed descriptions, including the confirm flag's role. The description's mention of confirm:true reinforces the schema but doesn't add new parameter-level detail. With 100% schema coverage, the baseline of 3 is appropriate.
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 tool sends a message to Crown Town Compost customer support, using a specific verb and resource. It distinguishes from sibling tools like report_missed_pickup and skip_service by focusing on general support contact.
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 does not mention when to use this tool versus alternatives such as report_missed_pickup or skip_service. However, the intended use is implied by the verb 'send a message to customer support,' and the dry-run note clarifies how to safely test the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only nature is covered. The description adds behavioral context by mentioning pagination, filtering by status, and listing the specific status values, which goes beyond the annotations. No contradiction exists.
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 concise with three short sentences that cover purpose, returned fields, and pagination/filtering. It wastes little space, though the status enum is somewhat redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description's enumeration of returned fields (date, status, collection time, weight, services rendered) is essential and well-provided. Combined with pagination, filtering, and the read-only annotation, the tool is fully contextualized for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning each parameter (page, status, per_page) already has a clear description. The description only redundantly mentions status filtering and provides no additional parameter detail beyond the 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 states 'List past collection stops for your account' with a specific verb and resource, and explicitly says 'past' to distinguish from the sibling 'list_upcoming_services'. It also enumerates the returned fields, making the purpose unmistakable.
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 clearly indicates this is for historical collection stops, which contextually differentiates it from the upcoming-services sibling. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by disclosing that without confirm:true it is a dry run that makes no network call, and that with confirm:true it notifies staff. This is key safety behavior not captured by readOnlyHint or openWorldHint.
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 two sentences, front-loaded with purpose, and contains no filler. The dry-run caveat is essential and placed at the end, keeping structure efficient.
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?
The tool has no output schema, but the description covers purpose, notification outcome, and dry-run behavior. It doesn't detail preview contents or the confirmed response, but for a simple report tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no meaning beyond the schema's parameter descriptions. It repeats the confirm dry-run behavior already present in the confirm property 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 uses a specific verb ('Report') plus a clear resource ('scheduled collection') and scope ('missed'), and states the outcome (notifies staff). It distinguishes from sibling tools like crowntown_skip_service by focusing on reporting a missed past collection.
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 when to use (when a scheduled collection was missed) but does not explicitly differentiate from alternatives like skip_service or contact_support. The dry-run guidance is useful for safe invocation but not for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by detailing the exact data returned (e.g., plan, price, renewal date, environmental impact). It confirms the read-only nature, aligning with annotations, and clarifies the scope of the dashboard.
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 a single sentence with a clear front-loaded verb and resource, followed by a compact list of dashboard components. It is information-dense without superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose and return content, which is essential given the absence of an output schema. It provides enough context for an agent to decide when to invoke it and what to expect.
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 zero parameters, so the schema provides complete coverage and there is nothing to document. The description correctly omits parameter details, meeting the baseline for 0-param tools.
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 verb 'Get' and the resource 'dashboard summary', and enumerates the specific contents (account status, subscription details, service dates, addresses, environmental impact). This distinguishes it from sibling tools like 'get_account' or 'list_service_history'.
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 this is a high-level summary tool through its list of aggregated data, but it does not explicitly state when to use it over alternatives or mention exclusions. No direct comparison to sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context beyond these: it notes pagination, lists the response fields (including links to Stripe PDF/receipt/hosted invoice page), and explicitly states 'Read-only' (redundant but consistent). This helps the agent know what to expect from the output.
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 a single, information-dense sentence followed by two short labels ('Paginated. Read-only.'). Every word adds value, and the key purpose is front-loaded. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 3 optional, well-documented parameters. No output schema, but the description enumerates all returned fields and notes pagination. Annotations cover safety and determinism hints. This is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter (page, per_page, payable_only). The description adds no parameter-specific semantics beyond mentioning pagination and 'whether payable', which are already covered. Baseline 3 is appropriate when the schema does the heavy lifting.
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 states a specific verb and resource: 'List your Crown Town Compost invoices', and enumerates the exact fields returned (number, date, amount, status, payable, links). This clearly distinguishes it from sibling tools like list_service_history or list_upcoming_services.
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 implies when to use it: any time the user needs billing/invoice history. It does not explicitly mention alternatives or exclusions, but the context is clear and no sibling tool overlaps, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses a critical behavioral detail: without confirm:true it is a dry run that returns a preview and makes no network call. This adds significant transparency about side effects and execution mode, which the annotations alone do not convey.
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?
Two concise sentences, front-loaded with the primary action and immediately giving the essential prerequisite. No filler or redundant text; every clause contributes meaningful information.
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?
The description covers prerequisites and the confirm gating, which is good. However, without an output schema it does not describe the preview format or the final response after a confirmed skip/unskip, leaving a small gap for a state-changing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a small value by highlighting confirm's dry-run behavior, but mostly reinforces the rid/clid source that the schema already documents. No major enrichment beyond the 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?
Description uses a specific verb ('Skip (or un-skip)') with a clear resource ('upcoming collection day'), which distinguishes it from sibling tools like report_missed_pickup and list_upcoming_services. The mention of passing rid + clid from crowntown_list_upcoming_services further grounds the tool's exact role.
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 a key prerequisite (obtain rid/clid from crowntown_list_upcoming_services) and clearly explains the dry-run behavior without confirm:true. It does not explicitly name when-not-to-use or alternatives, but the context is evident from the tool's action and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behavioral traits beyond the annotations: it reads the current account form, modifies only the specified fields, re-saves the rest verbatim, and requires confirm:true or else performs a dry run. This is critical for safe usage and fully covers the tool's side effects, especially given annotations only indicate readOnlyHint:false and openWorldHint:true.
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?
Two sentences, immediately front-loaded with the tool's purpose, and every clause serves a purpose. No unnecessary filler or repetition.
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?
The description covers the core operation: reads current form, updates specified fields, re-saves, and explains the confirm/dry-run mechanism. It does not describe the success response or error cases, but given there is no output schema and the tool is moderately complex, the coverage is solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter already has a description. The description adds context about the selective-field behavior and confirm:true dry-run, but it does not provide per-parameter details beyond what the schema already offers. This aligns with the baseline of 3.
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?
Description begins with 'Update your contact details and/or notification preferences' – a specific verb (Update) and resource (account), clearly distinguishing it from sibling tools like get_account, list_invoices, and healthcheck. The scope is explicit and unambiguous.
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?
Clear context: use this tool when the goal is to change account contact details or notification preferences. It does not explicitly mention alternatives or exclusion scenarios, but the read-modify-write behavior and confirm requirement are clearly stated, giving useful context for when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description adds valuable context: it explicitly states Crown Town Compost publishes no guaranteed arrival window, so the window is empirical and derived from recorded collection times. This explains the tool's behavior and data provenance, exceeding what annotations alone convey.
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 two concise sentences, front-loaded with the primary outcome and enriched with necessary caveats. Every sentence contributes meaning, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description enumerates exactly what is returned (pickup days, next service date, set-out time, observed window with earliest/latest/typical and consistency). It also covers the empirical derivation and absence of guaranteed times, making the tool's behavior fully understandable in context.
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 input schema fully documents history_sample with a clear description, type, default, and bounds. The tool description does not mention the parameter, but since schema coverage is 100%, the baseline of 3 is appropriate; no additional semantic value is needed.
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 tool fetches the pickup schedule for each service address, listing the exact elements returned (pickup days, next service date, set-out time, observed arrival window). This specific verb+resource combination distinguishes it from sibling tools like list_upcoming_services, which focus on individual upcoming services rather than the recurring schedule.
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 gives clear context on what the tool returns, implying when to use it (when you need the schedule and arrival-time window). It does not explicitly name alternatives or exclusions, but the behavioral detail about the observed window makes its purpose obvious relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, covering safety and side-effect expectations. The description adds context by specifying the exact data fields returned and reiterating the read-only nature, which is helpful beyond the annotations. It does not provide deeper behavioral details like authentication or rate limits, but for a simple getter with no parameters, this is adequate.
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 two sentences, front-loaded with the action and resource list, and the second sentence provides the alternative tool reference. Every word earns its place, with no redundant specification or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters, no output schema, and straightforward sibling set, the description fully covers what the tool does, what it returns (listed fields), and the read-only behavior. The alternative for changes is also highlighted, making the context complete for an agent to select and invoke correctly.
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 zero parameters, so the schema provides no burden and the baseline is 4. The description implicitly clarifies that the account identity is derived from the caller's context ('your account'), which adds a subtle semantic beyond the empty schema. No further parameter explanations are needed.
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 uses a specific verb 'Get' and clearly identifies the resource: account contact details (first name, last name, phone) and notification preferences (email reminders, service notifications). It distinguishes itself from the sibling tool crowntown_update_account by explicitly naming it as the alternative for changes, and from other list tools by focusing on account-level details rather than service history or invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Read-only — use crowntown_update_account to change them,' providing a clear when-to-use and naming the alternative for modifications. This guides the agent to select this tool for viewing account and notification settings without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description adds valuable behavioral context: it explains the login step, dashboard fetch, and the specific output fields (authenticated, account_status, service_addresses). It also reveals the error-handling nuance of distinguishing 'no creds', 'bad creds', and 'site error', which annotations do not cover.
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 a single, well-structured sentence that front-loads the action and compactly lists the output and error distinctions. It includes no filler and every phrase contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, but the description explicitly enumerates the return fields and the plain-English hint types. It covers the key behavioral aspects (read-only, auth check, portal access) sufficiently for a tool of this simplicity, and no additional details are necessary.
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 zero parameters, the description adds no parameter-specific semantics, but the baseline for 0 params is 4. The tool requires no input, so the description's behavior description fully covers what the agent needs to know about invoking it.
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 a specific action: confirming credentials, logging in, fetching the dashboard, and reporting a structured result. It distinguishes itself from siblings like crowntown_get_account or crowntown_get_dashboard by focusing on health verification rather than data retrieval or mutation.
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 implicitly communicates when to use the tool: as a healthcheck/auth verification before performing other portal operations. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, reducing the burden on the description. The description adds useful behavioral context: output includes both scheduled and already-skipped services, and it pulls from the service calendar. It also repeats 'Read-only' reinforcing safety, though it doesn't discuss pagination or ordering—acceptable for a simple list 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?
Two sentences, front-loaded with the verb and resource, no wasted words. The first sentence describes scope and output; the second gives clear usage guidance. Perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and helpful annotations, the description fully covers purpose, return content, and alternative tools. It is complete for an agent to select and invoke correctly, with no significant gaps.
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 zero parameters, the schema has no properties to explain, so baseline 4 applies. The description does not need to add parameter details and correctly focuses on output semantics instead.
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 tool lists upcoming scheduled collection days from the service calendar, specifying the output includes skip identifiers (rid, clid), service date, and skip status. This distinguishes it from siblings like list_service_history (past services) and skip_service (mutation). The verb 'List' and specific resource 'upcoming services' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs users to use crowntown_skip_service for skipping/unskipping, establishing a clear alternative and when this read-only tool is appropriate. It also implies use when needing identifiers to skip, giving practical guidance beyond basic purpose.
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:

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

Score Badge

Copy to your README.md:

[![crowntowncompost-mcp MCP server](https://glama.ai/mcp/servers/chrischall/crowntowncompost-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/crowntowncompost-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/chrischall/crowntowncompost-mcp'

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