Skip to main content
Glama

Alishahi Insurance

Get quote questions

get_quote_questions
Read-only

Get the questions to ask for one coverage (names, types and allowed choices). All are optional.

Input Schema

NameRequiredDescriptionDefault
coverageYesA coverage name from list_coverages, e.g. "Homeowners" or "Tow truck".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

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

The readOnlyHint/destructiveHint annotations already establish the safety profile, so the bar is lower. The description does add something beyond them by sketching the returned content and flagging optionality, but 'All are optional' is ambiguous — it is unclear whether it refers to the questions, the answers, or the returned fields, which muddies rather than clarifies behavior.

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?

Two short sentences with the core purpose front-loaded and no filler. The trailing sentence 'All are optional' is terse and cheap to read, though its ambiguity costs it the top score.

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?

For a simple one-parameter read tool with annotations covering safety, the description is adequate: it says what is fetched and roughly what comes back. With no output schema, however, the return contract stays vague and the 'All are optional' claim is never resolved, so an agent cannot fully anticipate the response.

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% and there is a single required parameter whose schema text already explains that the value comes from list_coverages with examples. The description's 'for one coverage' is a weaker restatement of that, so the baseline 3 applies.

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?

States a specific verb+resource (get quote questions) scoped to a single coverage, and even sketches the return shape (names, types, allowed choices). It does not name or contrast with siblings, but none of the listed siblings (list_coverages, submit_quote_request, etc.) overlap in purpose, so the agent can still disambiguate.

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?

There is no explicit when-to-use statement, no mention of the ordering relative to list_coverages or submit_quote_request, and no exclusions. Usage is only implied by the phrase 'for one coverage', leaving the agent to infer the workflow context.

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.

Resources