Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-availability-server Check availability for 2025-03-21"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A small Model Context Protocol (MCP) server written in TypeScript. It exposes two tools that an MCP-capable client (such as Claude Desktop or Claude Code) can discover and call:
check_availability — returns available appointment slots for a given date.
format_call_summary — turns a caller, intent and next action into a tidy SMS-style summary.
The server communicates over stdio, the transport MCP clients use to launch and talk to a local server process. The tool logic is self-contained so the server runs anywhere with no API keys or external services.
I build production AI systems that use tool-calling and orchestration (a conversational agent on the Anthropic API, and a phone voice agent on Telnyx). This repo is a clean, minimal example of authoring an MCP server: defining tools with typed input schemas, returning structured content, and serving them over the MCP stdio transport.
Related MCP server: Partner Booking MCP Server
Node.js 18 or later
npm install
npm run buildnpm start
# or
node build/index.jsThe server runs on stdio and logs availability-server: MCP server running on stdio to stderr.
Add this to your Claude Desktop MCP config (claude_desktop_config.json):
{
"mcpServers": {
"availability": {
"command": "node",
"args": ["/absolute/path/to/mcp-availability-server/build/index.js"]
}
}
}Restart Claude Desktop, and the two tools will be available in conversation.
check_availabilityInput | Type | Description |
| string ( | The date to check. Weekends return no slots. |
format_call_summaryInput | Type | Description |
| string | Caller name or number |
| string | What the caller wanted |
| string | The agreed next step |
MIT
Return available appointment slots for a given date (YYYY-MM-DD). Weekends return no slots.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses weekends return no slots, which is a behavioral trait. However, with no annotations, it lacks details on idempotency, side effects, or authentication requirements.
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 short sentences, no fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description states it returns available slots, but does not specify the return structure or error cases. Adequate for a simple tool, but could be more complete.
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 description reinforces the date format (YYYY-MM-DD) already in the schema pattern, adding slight value. However, it does not explain the role of the date beyond format. Schema coverage is 0%, so description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns available appointment slots for a specific date with the format YYYY-MM-DD. It differentiates from sibling 'format_call_summary' by focusing on availability checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention when not to use or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Format a concise SMS-style summary of an inbound call from caller, intent and next action.
| Name | Required | Description | Default |
|---|---|---|---|
| caller | Yes | Caller name or number | |
| intent | Yes | What the caller wanted | |
| next_action | Yes | The agreed next step |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states formatting but does not disclose output format details, validation behavior, or side-effects (e.g., whether it saves or just returns text). Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no wasted words, front-loaded with verb and purpose. Highly concise.
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 3-string formatting tool with no output schema, the description covers the essential purpose. Could be slightly more explicit about output format (e.g., character limit), but adequate given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% with clear descriptions for each param. Description adds 'SMS-style' context suggesting brevity, which enriches the expected output beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifically states the verb 'format' and resource 'concise SMS-style summary' along with components (caller, intent, next action). It clearly distinguishes from sibling 'check_availability' which is about availability checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a call summary needs formatting, but no explicit guidance on when not to use it or alternatives. The sibling tool provides some context but no comparative advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0check_availabilityformat_call_summaryThe two tools serve entirely different purposes—one for checking appointment availability and one for formatting call summaries—so there is no ambiguity between them.
Both tools use a clear verb_noun pattern with underscores (check_availability and format_call_summary), maintaining consistency.
With only two tools covering disparate domains (availability and call summaries), the tool count is too low for coherent scope; each domain would benefit from additional related tools.
The tool surface is severely incomplete for both implied domains: for availability, CRUD operations are missing; for call summaries, creation and editing are absent, leaving significant gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search NPPES providers and resolve NUCC specialty codes via MCP over STDIO or Streamable HTTP.
take-the-meeting MCP — wraps StupidAPIs (requires X-API-Key)
Hosted MCP server for Cliniko — patients, appointments, availability, and invoices for AI agents.
Hosted MCP server for the Healthie EHR & telehealth API: patients, appointments, charting, tasks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JulianThorpe/mcp-availability-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server