LobbyStack

List calls

list_calls

Read-onlyIdempotent

Lists calls the receptionist handled, newest first, with outcome, summary and caller details. Filter by start time to read a given day: take the business time zone from get_business and pass that day's local midnight bounds with their offset. outcome is appointment_booked, booking_incomplete, message_taken, conversation, answered_by_team or none. Use get_call for the transcript.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_calls"
  }
}

Input Schema

Name	Required	Description
`limit`	No	How many items to return, 1 to 100. Defaults to 25.
`cursor`	No	The next_cursor value from the previous page. Omit it for the first page.
`started_after`	No	Only calls that started at or after this time. ISO 8601 with a Z or numeric offset, for example 2026-09-26T00:00:00-04:00.
`started_before`	No	Only calls that started before this time. ISO 8601 with a Z or numeric offset, for example 2026-09-26T00:00:00-04:00.

Output Schema

Name	Required	Description
`data`	Yes
`has_more`	Yes
`next_cursor`	Yes	Pass as cursor to get the next page. Null on the last page.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds genuinely new behavioral context: default ordering is newest first, what fields come back, and the timezone/offset convention required for correct filtering. It does not mention pagination limits or rate behavior beyond what the schema says.

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?

Three sentences, front-loaded with what is listed and in what order, then filtering procedure, then the sibling handoff. The outcome enumeration is the only long element and it earns its place by giving exact valid values.

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?

An output schema exists, so return values need not be detailed, yet the description still names the key fields. Combined with the timezone workflow and the get_call handoff, an agent has everything needed to invoke this correctly on the first attempt.

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 coverage is 100%, so baseline is 3, but the description goes further by explaining how started_after and started_before must be combined with the business time zone and local midnight bounds with offset — meaning the schema does not convey. The enumerated outcome values refer to returned data rather than a filter parameter, which is slightly ambiguous but readable in context.

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?

States a specific verb and resource (lists calls the receptionist handled), the sort order (newest first), and the returned fields (outcome, summary, caller details). It also distinguishes itself from get_call by naming it as the transcript tool, so an agent can pick between them without opening either schema.

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?

Gives a concrete procedure for the main use case (read a given day by taking the time zone from get_business and passing local midnight bounds with offset) and redirects to get_call when the transcript is needed. It stops short of stating when not to use this tool or how to page through large ranges, but the routing guidance is well above generic.

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

All LobbyStack tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?