How do I use huddle-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@huddle-mcp book my agent briefings" 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.

huddle-mcp

by marcoloco23

Overview Schema Related Servers Score Discussions

JavaScript

Local

huddle-mcp

An MCP server that lets your parallel coding agents schedule briefings on your real calendar instead of interrupting you. They queue their plans and questions; the queue batches them by urgency into time-blocks booked when you're free.

When you run a fleet of agents, the bottleneck is you. Three plans and two questions land at once, on their schedule, and the context-switching wrecks your decisions. huddle-mcp is the fix real employees already use: don't barge in — book a meeting.

auth-agent  → request_meeting("JWT vs sessions", type=plan, urgency=blocker)
ui-agent    → request_meeting("dark-mode default?", type=question)
db-agent    → request_meeting("migration applied", type=fyi)

You: "book my agent briefings"
  → 🚨 Blocker · auth-agent: JWT vs sessions      11:05–11:15
  → 📋 Agent briefing · 2 items                    14:00–14:20  (the question + the FYI)

You review at the booked time; the agents wait and unblock once you've decided.

The idea: a broker, not another calendar wrapper

Wrapping a calendar is a solved problem (Google ships an official Calendar MCP; there are mature OSS ones). The value here is the coordination layer in front of it:

a shared queue any agent can drop a request into,
an urgency-aware batching policy (blockers get booked ASAP; routine items bundle into the next briefing; FYIs ride along and reserve no time),
a briefing renderer that aggregates everything into one agenda you skim.

So huddle-mcp is auth-free and provider-agnostic — it never touches your calendar. It emits the agenda + a desired time window, and the actual freebusy lookup + event creation is delegated to whatever calendar MCP you already have connected (Google, Outlook, …). Install = one line, zero new credentials.

Related MCP server: @calmesh/mcp-server

Tools

Tool	Who calls it	What it does
`request_meeting`	worker agent	Queue a plan/question/decision/fyi. Returns a `ticketId`. No calendar.
`check_response`	worker agent	Poll a `ticketId`; returns the user's decision once answered.
`cancel_request`	worker agent	Withdraw a ticket you resolved on your own.
`plan_meetings`	orchestrator	Batch the queue into proposed meetings + rendered briefings.
`confirm_meeting`	orchestrator	Record a booked calendar event; marks its tickets scheduled.
`get_briefing`	orchestrator	The rendered agenda + full tickets for a meeting.
`resolve`	orchestrator	Record the user's decision for one ticket → unblocks the worker.
`ingest_answers`	orchestrator	Parse the user's answers out of the event description and resolve every answered ticket at once.
`reopen`	orchestrator	Undo a decision and re-open the ticket (you changed your mind).
`discard_meeting`	orchestrator	Drop a meeting, re-queue its open tickets (stale proposals auto-expire after 24h).
`list_agenda`	orchestrator	What's queued / scheduled / answered.

How it fits together

The calendar event is two-way: huddle writes the briefing into it, and the user answers right there.

worker agents ──request_meeting──▶ [ huddle-mcp queue ]   (local JSON, file-locked)
   (auth, ui, db…)                       │ batch by urgency + render briefing
                                         ▼
                          plan_meetings → proposed meetings (window + duration + briefing)
                                         │
your orchestrator ──▶ your Calendar MCP: freebusy → create_event(description = briefing + answer block)
                                         │
                          confirm_meeting(meetingId, eventId, start, end)
                                         ▼
        ┌── you answer in the event:  "tkt_3f9a → use server sessions"
        │
        └─▶ orchestrator reads the event back ──▶ ingest_answers(description)
                                         ▲              (or resolve(ticketId, decision) in chat)
worker agents ──check_response(ticketId)─┘  poll, unblock, proceed

The briefing that lands in the event ends with a writable answer block:

— ✍️ Your answers —
Reply after each → then tell your agent "read my huddle answers".
tkt_3f9a2c1d → use server sessions
tkt_8b7e0a44 → ship dark mode as the default

When you say "read my huddle answers", the bundled huddle skill (in skills/huddle/) fetches the event via your calendar MCP, passes its description to ingest_answers, and every answered ticket resolves — the agents unblock. The same skill drives the booking side: "book my agent briefings" runs plan_meetings, finds free slots, and creates the events. huddle itself never touches the calendar — the skill bridges it.

Requirements

Node.js ≥ 20
A calendar MCP connected in the same client (e.g. Google Calendar) for the actual booking. huddle-mcp itself needs no account and no auth.

Install — Claude Code

{
  "mcpServers": {
    "huddle": {
      "command": "npx",
      "args": ["-y", "huddle-mcp"]
    }
  }
}

That's it — no env vars. (Prefer the bleeding edge? Use "github:marcoloco23/huddle-mcp" instead of "huddle-mcp".) Connect a Google Calendar MCP alongside it for booking, and (optionally) copy skills/huddle/ into ~/.claude/skills/ so "book my agent briefings" and "read my huddle answers" just work.

From source

git clone https://github.com/marcoloco23/huddle-mcp.git
cd huddle-mcp
pnpm install   # builds via the prepare hook
node dist/index.js

For agent authors

Worker agents should queue and wait, never block the user inline:

request_meeting({ agent, title, body, type, urgency?, estimated_minutes? })
  → { ticketId }
# do other work, then:
check_response({ ticket_id })  → { answered, response }   # proceed once answered

type: question (needs an answer) · plan (review a plan) · decision (pick an option) · fyi (no action).
urgency: blocker (book ASAP) · normal / low (bundle into the next briefing). Default normal.

Storage

The queue is a single JSON file shared by every agent process, at ~/.config/huddle-mcp/queue.json (honors XDG_CONFIG_HOME; override with HUDDLE_HOME). Concurrent writes from parallel agents are guarded by an atomic cross-process lock.

Developing & releasing

npm install        # builds via the prepare hook
npm test           # node:test — pure units + a stdio server integration suite

CI runs the suite on every push/PR. Releases are automated: bump the version in package.json, then cut a GitHub Release — the publish workflow builds, tests, and pushes to npm. It needs an npm automation token (which bypasses 2FA) saved once as the NPM_TOKEN repo secret (Settings → Secrets and variables → Actions).

Roadmap

Where this is headed — autonomy (agents book themselves), closing the last mile (answered → agent actually resumes), notifications, smarter briefings, Outlook, and more — is in ROADMAP.md, ranked by how much it protects your attention.

License

MIT

Available Tools

8 tools

cancel_requestWithdraw a requestB

Cancel a queued ticket you no longer need (e.g. you resolved it yourself).

ParametersJSON Schema

Name	Required	Description	Default
`reason`	No
`ticket_id`	Yes

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description only states the action without disclosing side effects, permissions, or return behavior. For a mutation tool, more transparency is needed.

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?

Single sentence with example, efficient and front-loaded. However, could be slightly more structured.

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 0% schema coverage and no output schema, the description is too minimal to fully guide invocation. Missing details on what occurs after cancellation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No description of the two parameters (ticket_id, reason). Schema coverage is 0%, and the description adds no parameter meaning.

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?

Clearly states the action ('Cancel a queued ticket') and gives a specific example ('you resolved it yourself'). Differentiates from sibling tools like 'resolve' and meeting-related tools by referring to queued tickets.

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?

Provides one example of when to use the tool, but no explicit guidance on when not to use or alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_responseCheck for the user's decisionC

Poll a ticketId. When answered is true, response holds the user's decision and you can proceed.

ParametersJSON Schema

Name	Required	Description	Default
`ticket_id`	Yes

TDQS

C2.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description reveals the polling nature (repeated calls) and the condition for proceeding ('when answered is true'), which implies non-blocking behavior. However, with no annotations, it lacks details on side effects, error states (e.g., invalid ticketId), or whether the tool is read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (two sentences) but poorly structured. It jumps into the 'answered' condition without first stating the tool's purpose or return format. It is efficient but lacks clarity in flow.

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 a single parameter, no output schema, and no annotations, the description is incomplete. It does not specify what the tool returns, how to interpret the response, or what to do if the ticketId is invalid. The level of detail is insufficient for reliable tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% coverage, and the description only says 'Poll a ticketId', without explaining what the ticket_id represents or how it relates to the user's decision. This adds minimal meaning beyond the schema's type constraint.

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 polls a ticketId and checks for the user's decision via the 'answered' flag. It mentions the 'response' field, giving a clear verb-resource mapping. However, it does not explicitly differentiate from sibling tools like 'get_briefing' or 'resolve', which might also involve checking statuses.

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. The description implies it should be used after a request has been made, but does not state prerequisites, exclusions, or when to stop polling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

confirm_meetingRecord a booked meetingA

After you create the calendar event, record it here. Marks the meeting booked and its tickets scheduled.

ParametersJSON Schema

Name	Required	Description
`end`	Yes	ISO end time.
`start`	Yes	ISO start time the event was booked at.
`meeting_id`	Yes
`calendar_event_id`	Yes	The id returned by your calendar MCP.

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It states the tool 'Marks the meeting booked and its tickets scheduled,' which indicates a state change but does not disclose idempotency, permissions, or effects of re-recording. Adequate but lacks depth.

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 short sentences, front-loaded with the key instruction, and contains no unnecessary words. Highly 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 no output schema, no annotations, and 4 required parameters, the description covers the main purpose and timing but lacks details on prerequisites, error handling, or behavior on multiple calls. Adequate but not fully complete.

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 high (75%), so the baseline is 3. The description adds no extra meaning beyond the schema; it does not explain the 'meeting_id' parameter which lacks a schema description. No improvement over structure.

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 is for recording a meeting after creating the calendar event, using specific verb 'record' and resource 'meeting'. It distinguishes from sibling tools like 'request_meeting' and 'cancel_request' by specifying it as a post-creation step.

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 explicitly states 'After you create the calendar event, record it here.', which provides clear timing for use. However, it does not specify when not to use it or mention alternatives, so it gets a 4.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_briefingGet a meeting's briefingC

Return the rendered agenda for a meeting (use as the calendar event description, or to re-read at review time) plus its full tickets.

ParametersJSON Schema

Name	Required	Description	Default
`meeting_id`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses the return values but does not mention whether the tool is read-only, requires authentication, or any side effects. This is insufficient for a tool with no safety hints.

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 (two sentences) and front-loaded with the core purpose. It could be slightly more structured but is 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 no annotations and no output schema, the description provides adequate context for a simple tool with one parameter. However, it lacks details on parameter constraints, error conditions, and response format, leaving gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no explanation for the sole parameter 'meeting_id'. The parameter type and name are present in the schema, but no additional meaning is provided.

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 it returns a rendered agenda and full tickets for a meeting, and provides usage context (calendar event description, review time). However, it does not differentiate from the sibling tool 'list_agenda', which may have overlapping functionality.

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 gives implied usage scenarios (calendar event description, review time) but does not explicitly state when to use this tool over alternatives like 'list_agenda' or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_agendaShow the agendaB

Overview of tickets and meetings. Optionally filter tickets by status (queued | scheduled | answered | cancelled).

ParametersJSON Schema

Name	Required	Description	Default
`status`	No	Filter tickets by status.

TDQS

B3.3/5.0

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 fails to disclose whether the tool is read-only, what happens to the agenda upon invocation, or any side effects. The ambiguity about meetings (status filter only applies to tickets) is not resolved.

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 that conveys the core purpose and optional parameter without redundancy. Every word earns its place.

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?

With one optional parameter, no output schema, and no nested objects, the description is mostly adequate. However, it does not specify return format or whether meetings are always included, leaving some gaps.

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 the baseline is 3. The description adds minimal value by restating that status filters tickets, which is already in the schema's enumeration and description.

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 provides an 'Overview of tickets and meetings' with optional filtering by status. This verb+resource structure distinguishes it from sibling tools like 'cancel_request' or 'confirm_meeting', which are single-action tools.

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 given on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use it, or suggest other tools for specific scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

plan_meetingsBatch the queue into meetingsA

Group all newly-queued tickets by urgency into proposed meetings (pure — books nothing). Returns every unbooked meeting with desiredWindow, durationMinutes and briefingMarkdown so you can find a slot via the calendar MCP and then call confirm_meeting.

ParametersJSON Schema

Name	Required	Description	Default
`max_block_minutes`	No	Cap on a single bundled briefing (default 45); overflow spills to another block.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description clearly states the tool is 'pure — books nothing' and describes return values, providing good transparency for a simple read-only planning 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 convey purpose, behavioral constraints, output, and workflow without waste, 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?

Covers purpose, behavior, output, and workflow sufficiently for a simple tool, but could mention prerequisites (e.g., requiring newly-queued tickets) for full completeness.

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 description adds meaning beyond the schema by explaining the default (45 minutes) and behavior on overflow ('spills to another block'), fully enriching the single parameter.

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 it groups newly-queued tickets into proposed meetings without booking anything, and distinguishes from sibling tools by mentioning the subsequent 'confirm_meeting' step.

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 (after queuing tickets, before confirming) and how to proceed (use calendar MCP then confirm_meeting), but does not explicitly state exclusions or compare to alternatives like request_meeting.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

request_meetingRequest a briefingA

Queue a request for the user instead of interrupting them. Returns a ticketId; poll check_response with it and proceed once answered. Does not touch the calendar.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	The full plan / question / context the user needs to decide.
`type`	Yes	question = needs an answer; plan = review a plan; decision = pick an option; fyi = no action.
`agent`	Yes	Your agent name/role, e.g. 'auth-agent' — shown in the briefing.
`title`	Yes	One-line summary of what you need.
`urgency`	No	blocker = book ASAP; normal/low = bundle into next briefing. Default normal.
`estimated_minutes`	No	How long the user needs to decide. Default 10 (fyi defaults to 0).

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so description carries full burden. It reveals the tool creates a request (write operation) and doesn't affect the calendar, but misses details like authentication needs or data persistence. Adequate but not exhaustive.

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 key purpose, no fluff. Every sentence adds value.

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?

Description covers the workflow (queue, poll check_response) and important constraint (no calendar). With 100% schema coverage for parameters and no output schema needed, the description is fully complete for this tool's complexity.

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 baseline is 3. The description does not add extra parameter semantics beyond the schema, leaving baseline unchanged.

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 clearly states the tool queues a request non-interruptively, returns a ticketId, and does not touch the calendar. It distinguishes from siblings like check_response and confirm_meeting.

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?

Provides clear context: use when you need to ask the user without interrupting, and poll check_response for an answer. Does not explicitly state when not to use, but the calendar note and sibling names give indirect guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resolveRecord the user's decisionA

Record the user's answer/decision for a ticket. Flips it to answered so the waiting worker unblocks on its next check_response.

ParametersJSON Schema

Name	Required	Description	Default
`decision`	Yes	The user's answer, decision, or direction.
`ticket_id`	Yes

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must be self-sufficient. It discloses a key behavioral trait: the tool flips the ticket state to 'answered', enabling a waiting worker to proceed. However, it omits other possible side effects, such as whether the action is reversible, permission requirements, or limitations on repeated calls.

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 primary action, and adds a contextual effect. Every word is necessary; there is no fluff.

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 (2 params, no output schema, no annotations), the description covers the core functionality and its place in the workflow (unblocking check_response). It could mention what the tool returns or error conditions, but this is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (decision is described, ticket_id is not). The description says 'for a ticket', which loosely links ticket_id to a ticket context, but it does not clarify the format or purpose of ticket_id beyond its name. The description fails to compensate for the missing schema detail.

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 action: 'Record the user's answer/decision for a ticket.' It also provides context on the subsequent effect (flipping to answered, unblocking worker). This verb+resource pairing is specific and distinguishes the tool from sibling tools like cancel_request or confirm_meeting.

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 when needing to record a user's decision and unblock a worker. It mentions 'on its next check_response', tying to a specific workflow, but it does not explicitly state when not to use this tool or provide alternative tools for similar purposes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool serves a distinct purpose: cancel_request, check_response, confirm_meeting, get_briefing, list_agenda, plan_meetings, request_meeting, and resolve all have clearly different functions with no overlap. An agent can easily select the correct tool.

Naming Consistency4/5

Most tools follow a verb_noun pattern (e.g., cancel_request, confirm_meeting), but 'resolve' is a single verb, slightly breaking the pattern. The naming is otherwise consistent and readable.

Tool Count5/5

With 8 tools, the server covers the ticket-based meeting workflow without being too few or excessive. Each tool earns its place in the domain.

Completeness5/5

The tool set covers the full lifecycle: requesting, cancelling, planning, confirming, polling, resolving, and listing. External calendar integration is explicitly delegated, leaving no dead ends.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

llm-bus
com.llm-bus
Coordinate multiple AI agents over MCP: atomic claims, leases, shared ledger, handoffs, tasks.
Agent Orchestration Autonomous Agents
29
Octopad
app.octopad
The back-office workspace for your team's AIs: tasks, knowledge and context shared over MCP.
Project Management Knowledge & Memory Agent Orchestration
2
aXOAuthDeprecated
io.github.ax-platform
Agent-native collaboration network: orchestrate a team of long-running agents from any MCP client.
Knowledge & Memory Autonomous Agents Agent Orchestration
36
AgentDM: Agent to Agent Communication Platform
ai.agentdm
Agent communication platform for agent to agent messaging via MCP. Messages, channels, skills.
Autonomous Agents Communication Agent Orchestration
2

Related MCP Servers

Temporal Cortex MCP
Autonomous Agents Calendar Management Developer Tools
temporal-cortex
A
license
A
quality
C
maintenance
Calendar MCP server with atomic booking, conflict prevention, deterministic RRULE expansion, and TOON token compression for AI agents.
Updated 3 days ago (2026-08-31 21:06 UTC)
18
12
MIT
@calmesh/mcp-server
Calendar Management Workplace & Productivity
davidklemme
A
license
A
quality
D
maintenance
MCP server that connects AI agents to calendars, bookings, and scheduling polls via the Model Context Protocol.
Updated 3 months ago (2026-06-09 17:26 UTC)
22
17
MIT
mcp-switchboard
Communication Autonomous Agents
Jemplayer82
A
license
Not graded
quality
A
maintenance
A real-time inter-agent switchboard, delivered as one centralized streamable-HTTP MCP server. Any MCP-capable agent can message, coordinate, and stay ambiently aware of others.
Updated 7 days ago (2026-08-28 00:42 UTC)
AGPL 3.0
calendar-mcp
Calendar Management Workplace & Productivity
apex-500
A
license
Not graded
quality
Not graded
maintenance
MCP server that lets AI agents manage Google Calendar -- create events, check availability, and manage schedules.
Updated 6 months ago (2026-03-13 05:27 UTC)
MIT

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/marcoloco23/huddle-mcp'

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