get_renewalsPolicies renewing within a window. Optional input { days?: number }, default 90. Same summary fields as list_policies — no document bodies.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-ahead window in days. Defaults to 90. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already communicate that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral context by stating that results share list_policies' summary fields and contain no document bodies. It does not disclose ordering, pagination, or other edge -case behavior, but the annotation coverage lowers the bar and the additional context is adequate.
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?
The description is three concise sentences with the core purpose front-loaded. Each sentence earns its place: the purpose, the optional parameter/default, and the output shape comparison. There is no redundant or filler content.
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, single-optional-parameter read tool with no output schema, the description covers what the tool does, how the parameter behaves, and what the return content looks like. The return description relies on the sibling list_policies to define the exact summary fields, which is reasonable in a shared MCP context but not fully self-contained. Overall it is sufficient for correct invocation.
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 schema fully describes the sole parameter, days, including type, range, and default value. The description repeats that days is optional and defaults to 90 without adding new semantics. Since schema description coverage is 100%, the baseline of 3 is appropriate and the description adds no meaningful parameter insight beyond the 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 clearly identifies the resource as policies renewing within a look-ahead window, which is a specific, actionable scope. The reference to list_policies and the note about document bodies helps distingish it from the sibling list_policies and other tools. The name, title, and description align with no ambiguity.
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 intended use case is explicit: retrieve policies that renew within a configurable window, defaulting to 90 days. It also implies that document bodies are not included, which signals when list_policies may be more appropriate. However, it does not explicitly state when not to use this tool or name an alternative for full-document retrievals, so it falls just short of perfect guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct action: adding a policy, asking a coverage question, listing renewals, viewing vault metadata, ingesting a document, and listing policies. Even the two list-like tools serve clearly different purposes, and descriptions reinforce the boundaries.
All tool names follow a consistent snake_case verb_noun pattern: add_policy, ask_coverage, get_renewals, get_vault, ingest_document, list_policies. There are no mixed conventions or vague generic verbs.
Six tools is well-scoped for an insurance vault assistant: the set covers ingestion, manual entry, policy summaries, renewal lookups, vault metadata, and natural-language coverage queries without bloat.
The core flows are covered—add/list policies, ingest documents, ask about coverage, and see renewals—but there is no update or delete for policies, and no way to list or manage documents that landed in the inbox. These are notable gaps for a lifecycle-complete surface, though they may be intentional for a privacy-focused read/input tool.