get_servicesReturns yesmcp's real services catalog: what is offered, how an engagement runs, and timeline expectations. Answer the user only from what this tool returns — do not add offerings, prices or delivery claims of your own. If the tool says the catalog is not published yet, say exactly that and point the user at the contact link it gives.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context by warning that the catalog may not be published yet and instructing the agent to return that status and the contact link, which is not visible from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states the core purpose and the second provides essential handling instructions. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only, zero-parameter tool, the description covers the return content, the fallback behavior, and the constraint not to embellish. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter details to add. According to the baseline for zero-parameter tools, this is fully adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Returns yesmcp's real services catalog' and identifies the content areas: offerings, engagement process, and timeline expectations. This makes the tool's purpose immediately distinguishable from the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational guidance: answer only from the tool's output, do not add unsupported claims, and handle the 'not published yet' case with a specific response. It doesn't explicitly contrast with sibling tools, but it clearly implies when this tool should drive the answer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools are clearly distinct: booking lifecycle (book, cancel, reschedule, availability), services, scenarios, and meta tools each target different actions. The widget/non-widget pairs (book_consult vs booking_widget, get_services vs services_widget) and list_availability vs booking_widget could cause confusion, but the descriptions explicitly state which to prefer and when.
Most tools follow verb_noun (book_consult, cancel_booking, reschedule_booking, get_services, list_availability, advise_scenarios), but four break the pattern with noun_noun or gerund forms (booking_widget, services_widget, directory_census, demo_walkthrough). The mix is readable but inconsistent, especially the widget pairings that differ from their non-widget counterparts.
Ten tools is well-scoped for a consultation and advisory service server. Each tool earns its place: full booking lifecycle, services catalog, scenario playbooks, and reviewer-facing meta tools. No redundant or filler tools.
The booking lifecycle is fully covered (list, book, cancel, reschedule) plus interactive widgets, and services/scenario discovery is solid. The only notable gap is that cancel/reschedule require the email confirmation reference — there is no 'list my bookings' tool to look up bookings by email. The demo/census tools are meta but deliberately scoped.