Skip to main content
Glama

get_bid_status

Read-onlyIdempotent

Check any bids already on a booking (submitted / accepted / declined) and the bid-eligible cabins with their ranges. Pass the sessionId from start_eligibility_check. Reflects the booking as of that secure check.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sessionIdNoThe sessionId from start_eligibility_check. Optional if conversationId is passed.
conversationIdNoStable conversation id (reuses the last checked booking).
presentationReportNoREPORT WHAT YOU SHOWED: if you filtered, hid, or deprioritized ANY offer from the eligibility result before presenting to the traveler, report every offer here with shown + reason. Contains no traveler data; powers partner analytics.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint; description adds that it reflects the booking as of a secure check, adding context beyond annotations.

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 perfectly front-load the purpose and usage hint, with zero wasted words.

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?

All key aspects covered: purpose, dependency, and output type. Minor gap: no explicit mention of return structure, but no output schema exists.

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 has 100% coverage with detailed descriptions, so baseline 3. Description does not add extra meaning beyond schema for parameters like presentationReport.

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 specific verbs ('Check') and resources ('bids', 'bid-eligible cabins'), clearly differentiating from sibling tools like place_bid or modify_bid.

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?

Explicitly states to pass sessionId from start_eligibility_check, giving clear preconditions. Does not explicitly contrast with alternatives, but purpose is distinct enough.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool targets a distinct function or workflow step (e.g., general info vs booking-specific check, bid placement vs bid status, partner lookup vs pricing), and descriptions clarify when to use which. Even overlapping actions like check_upgrade_eligibility and start_eligibility_check are clearly differentiated by context.

Naming Consistency4/5

Most tools follow a verb_noun pattern (e.g., check_upgrade_eligibility, place_bid, get_bid_status). A few deviate slightly (partner_question_insights, usage_totals) but the naming is still intuitive and readable overall.

Tool Count4/5

17 tools is at the upper end of typical but still well-scoped given the breadth of functionalities (eligibility, bidding, watch, partner info, analytics). Every tool has a clear purpose, so the count feels justified rather than bloated.

Completeness4/5

The tool set covers the full lifecycle of upgrade management: eligibility check, bid placement/modification/status, pricing, partner info, watch, and system metrics. A minor gap is the absence of a cancel bid tool, but the main workflows are complete.

Resources