Insurance Wiki MCP Server

by sluyasu

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation5/5
Each tool targets a distinct operation: navigation (list_countries, list_branches), retrieval (get_branch_overview, get_page, get_product), focused coverage lookup (get_coverage), claim verification (verify_claim), comparison (compare_products), and overlap detection (find_overlap). Even where tools operate on similar data (products/coverages), their purposes are clearly differentiated.
Naming Consistency5/5
All tool names follow a consistent verb-first pattern: 'list_' for enumeration, 'get_' for retrieval, and specific action verbs for other operations (search, verify, compare, find). The naming is uniform and predictable across the set.
Tool Count5/5
10 tools is well-scoped for an insurance knowledge server. Each tool provides a distinct capability without redundancy or fragmentation, covering browsing, searching, retrieving, verifying, comparing, and analyzing insurance data.
Completeness4/5
The tool set covers the core lifecycle of querying insurance wiki data: navigation, search, retrieval, product details, coverage queries, claim verification, and comparison. Minor gaps exist (e.g., no direct list_insurers or list_regulations), but the search tool with filters compensates for these adequately.
Average 4.1/5 across 10 of 10 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 203 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries some burden. It discloses that the page is 'hand-authored' and that lookup is by slug or label, adding useful context. However, it doesn't mention read-only nature, error cases, or output format, but the verb 'Return' implies a safe read operation.
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?
One concise sentence, front-loaded with the action and resource. No wasted words; every word earns its place.
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 there is an output schema, return values are covered, but the lack of usage guidelines and parameter semantics makes the description incomplete for effective tool selection and invocation. It doesn't clarify how this differs from get_page or what the country parameter is for.
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 0%, and the description only says 'by slug or label' without explicitly mapping parameters. It doesn't explain that 'branch' is the slug/label or the role of 'country'. The description adds minimal meaning beyond the bare parameter names.
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 uses a specific verb (Return) and resource (hand-authored overview page for a branch), clearly distinguishing it from siblings like list_branches or get_page. The qualifier 'by slug or label' adds scoping, though it doesn't mention the country parameter.
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 on when to use this tool vs alternatives. It doesn't explicitly contrast with get_page or list_branches, nor mention any exclusions. The context implies it's for branch overviews, but no direct when-to-use advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It clearly describes the return content (counts and specific metrics), which is useful. However, it does not mention whether the operation is read-only, potential side effects, rate limits, pagination, or how the returned data is structured beyond field names. The 'list' phrasing implies a safe read, but explicit behavioral context is missing.
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 a single sentence that front-loads the main action ('List countries covered') followed by the specific metrics. It is reasonably concise, though the packed list of technical terms (branches_covered, branch_taxonomy, branch_overview_pages) makes it slightly dense. No unnecessary verbiage is present.
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 that this is a simple no-parameter tool with an output schema present, the description is largely complete. It explains the meaning of key output fields (e.g., branches_covered, branch_taxonomy) that might otherwise be ambiguous. The complexity is low, so the description sufficiently covers the contextual needs for an agent to select and invoke the tool.
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?
The input schema has no parameters, so the parameter semantics baseline is 4. The description does not need to explain parameters because there are none, and it instead focuses on what the output contains, which adds value beyond the schema.
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 lists countries and enumerates the specific metrics included (product/insurer/regulation counts, branches_covered, branch_taxonomy, branch_overview_pages). This makes the purpose unambiguous and distinguishes it from sibling tools like list_branches, which focus on branches rather than country-level aggregates.
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 guidance on when to use this tool versus alternatives such as list_branches or get_branch_overview. The description implies it is for obtaining country-level statistics, but it does not state that it should be used over others or provide any exclusion criteria. As a no-parameter tool, usage is straightforward, but the absence of comparative guidance leaves the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden. It implies a read-only operation via the verb 'list' and describes the output content, but it does not disclose other behavioral traits like pagination, ordering, or authentication requirements.
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, front-loaded sentence that efficiently conveys the tool's purpose and key output fields. There is no extraneous information.
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?
For a simple tool with one parameter and an output schema, the description adequately explains the purpose and expected outcomes. It does not mention caveats or prerequisites, but the minimal complexity makes this sufficient.
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 schema has no description for the 'country' parameter (0% coverage), and the description only repeats that the tool lists branches 'for a country.' It does not clarify the expected format (e.g., ISO code) or the default value ('be'), failing to compensate for the schema's lack of 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 it lists insurance branches for a country, specifying the returned fields (labels, mandatory flag, product counts). This distinguishes it from sibling tools like list_countries and get_branch_overview.
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 gives clear context: the tool is for listing branches for a specific country. However, it does not explicitly mention alternatives or when not to use it, lacking exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a good job: it discloses that the tool returns only matching excerpts, does NOT judge, and treats absent evidence as NOT SUPPORTED. It doesn't mention rate limits or permissions, but for a read-only evidence check this is reasonably transparent.
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?
Every sentence earns its place: purpose, output format, non-judgment behavior, missing-evidence rule, and usage intent are all covered in a compact, front-loaded structure. It is substantive without being bloated.
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?
The tool has an output schema, so return value details needn't be repeated. The description covers purpose, output, interpretation, and usage, making it self-sufficient for selecting and invoking the tool. It could slightly improve by mentioning relationship to sibling search tools, but overall it is complete.
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 0%, so the description must compensate. It provides helpful examples for the `claim` parameter but offers no explanation of country, insurer_slug, or product_name beyond the parameter names. Most parameters' expected values and formats remain undefined.
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's function: a verbatim evidence check for ONE factual claim about a product. It names the returned artifacts (document excerpts) and explicitly says the tool does NOT judge, which distinguishes it from sibling tools like search, get_page, or compare_products.
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?
It gives explicit guidance on when to use it: as a self-check before asserting product facts. It also explains how to handle missing evidence. However, it doesn't name alternative tools or state when NOT to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses case-insensitive substring matching, optional filters, and the multi-document selection rule (newest general conditions returned, others listed under `other_documents`). It stops short of describing error/not-found behavior, but the core is transparent.
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 roughly 150 words, front-loaded with the primary purpose, and every sentence adds value: output format, matching rule, filter semantics, and edge-case handling. It uses concrete examples like `'2026'` and document type values without redundancy.
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?
For a 5-parameter tool with no annotations and an existing output schema (per context signals), the description covers the key behaviors, filters, and the `other_documents` edge case. It lacks explicit handling for no-match scenarios and doesn't clarify `country`/`insurer_slug`, but overall it is sufficient for a competent agent to invoke it correctly.
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 0%, so the description must compensate. It explains `product_name` matching (case-insensitive substring), enumerates `document_type` allowed values, and gives an `edition` example with substring semantics. However, `country` and `insurer_slug` are not elaborated, though their roles are inferable from field names.
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 opens with a specific verb ('Return') and resource ('a product's structured data ... as JSON'), clearly distinguishing it from sibling tools focused on branches, coverages, or general search. It also mentions `source_url` and the `other_documents` field, which further clarifies scope.
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 by explaining the matching and filtering behavior, but it does not explicitly state when to choose this tool over alternatives like `search` or `compare_products`. There are no exclusions or alternative-naming mentions, so the guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself. It mentions the restriction to text files with specific extensions and that it returns full text. However, it does not address error handling or access requirements, leaving some ambiguity for edge cases.
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, front-loading the primary purpose and adding a constraint in the second sentence. There is no redundant information or unnecessary wording.
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?
The tool has a single parameter, an output schema exists (as signaled), and the complexity is low. The description provides the purpose, path semantics, and file-type restrictions, making it sufficiently complete for the agent to use the tool correctly.
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?
The schema provides no description for the 'path' parameter (0% coverage), but the description compensates by explaining that the path is repo-relative and typically comes from search results. It also lists accepted file types, giving meaningful semantics to the 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 the tool returns the full text of a knowledge page using a repo-relative path, and specifies the allowed file extensions. This distinguishes it from sibling tools like get_product or get_coverage, which target different resources.
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 phrase 'from search results' provides clear context that the tool is intended to be used after a search returns a path. It does not explicitly mention alternatives or exclusions, but the context is sufficient for a simple getter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool is deterministic + heuristic, surfaces likely duplicates for human confirmation, does not advise or rank, can miss overlaps, and explains document selection logic (general conditions over IPID, newest edition). This is rich, honest behavioral context.
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 moderately long but every sentence earns its place: purpose, mechanism, limitations, and parameter guidance. It is front-loaded with the core verb and resource, and 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (combining multiple products, heuristic behavior) and the presence of an output schema, the description is mostly complete: it covers purpose, behavior, limitations, and parameter constraints. The only gap is the lack of explicit explanation for the 'country' and 'on' parameters, though their roles are partially implied by the description of coverages/exclusions.
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 0%, so the description must compensate. It explains insurer_slugs explicitly (same length/order, pins each name to insurer) and product_names implicitly as the products to combine. However, it does not explicitly explain the 'on' parameter (default 'coverages') or the 'country' parameter, leaving semantics partially undocumented.
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 opens with a specific verb and resource: 'Flag CANDIDATE duplicate cover when combining 2+ products.' It clearly states the tool's scope (coverages/exclusions tagged by category) and distinguishes itself from sibling tools by noting it does not advise or rank, only surfaces likely duplicates for agent confirmation.
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 clearly states when to use the tool ('when combining 2+ products') and provides guidance on the insurer_slugs parameter (same length/order as product_names). It also notes limitations ('can miss overlaps the taxonomy doesn't yet cover'), which implicitly tells the agent when not to rely solely on this tool, but it does not explicitly name alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses return fields (path, source_url, freshness) and the truncation behavior when more than `limit` pages match, adding useful behavioral context beyond the schema.
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, front-loaded with the primary action, then filters, then return behavior. It is succinct and every sentence adds value without any redundancy.
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?
The description covers the main search behavior and the output schema handles return values. It adds a helpful note about truncation beyond the limit, but it omits the `country` parameter from the schema and does not reference sibling tools for comparison, leaving a mild completeness gap.
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?
With 0% schema description coverage, the description must compensate. It explains `query` (searches title/branch/insurer and page content), `type` (lists allowed values), and the slug filters for branch and insurer. However, `country` is not mentioned, and `limit` is only alluded to in the truncation note, leaving some gaps.
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 'Search wiki pages by title/branch/insurer and page content,' specifying both the action and the resource. This distinguishes it from sibling tools like get_page and get_product, which focus on retrieval rather than search.
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 provides clear context for when to use this tool: to search wiki pages with filters. It does not explicitly mention alternatives or exclusions, but the search-focused wording implicitly separates it from retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses important behaviors: case-insensitive matching, refusal on ambiguous names with candidates listed, document selection logic (general conditions over IPID, newest edition), and inclusion of superseded flags in the response. This is substantial, though it does not address potential side effects (e.g., read-only nature, error handling for no matches) that could be expected.
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 compact yet information-dense. Every sentence serves a purpose: first defines the main action, then details matching rules, next explains ambiguity handling, and finally document selection. No fluff or redundancy; ideal structure for AI consumption.
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?
With an output schema present, return values are already documented, so the description can focus on behavior. It covers key edge cases (ambiguous names, document selection) and usage constraints. However, it omits potential error scenarios or handling for mismatched array lengths, which could leave the agent uncertain in unusual cases. Still, for a tool of this complexity, it is largely complete.
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?
Schema description coverage is 0%, meaning the description must compensate. It does so excellently: explains product_names (case-insensitive matching), insurer_slugs (same length/order, pins names), and 'on' (dimension choices). Even country, while not explicit, is self-evident and not problematic. The description adds significant semantic meaning beyond the raw schema.
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's function: 'Compare 2+ products side by side on one dimension: coverages | exclusions | deductibles.' This is a specific verb+resource with explicit scope, distinguishing it from sibling tools like get_product (single product) and find_overlap (overlap analysis).
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 provides clear usage context: use this when comparing multiple products on a chosen dimension. It also gives practical guidance on passing insurer_slugs and handling ambiguous names. However, it does not explicitly contrast with alternatives or state when not to use the tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that matching is accent- and case-insensitive, that the response includes limits, deductibles, quotes, and page numbers, and that an empty list is not proof of absence. It could additionally state that the operation is read-only, but 'view' and 'get' strongly imply it.
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 compact and front-loaded: the first sentence gives the essence, the second gives the usage preference, and the third gives critical behavioral semantics. Every sentence adds value and there is no fluff.
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?
The description is fully adequate for this moderately complex tool: it states scope, content of the response, behavior on no matches, and which sibling to prefer. An output schema exists, so the description does not need to enumerate return fields.
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?
The schema provides no descriptions for any parameter (0% coverage), so the description must compensate. It thoroughly explains the key `topic` parameter with examples and matching behavior, and implicitly clarifies product-scoping params (country, insurer_slug, product_name). However, it does not explain optional parameters `edition` and `document_type` or the expected format of slugs.
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 states a specific verb ('get'/'view'), a specific resource (ONE product's coverages/exclusions), and a focused scope (relevant to a topic). It also explicitly distinguishes itself from the sibling tool get_product by saying 'Prefer this over get_product'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool: 'when answering a specific guarantee question'. It also names the alternative (get_product) and explains why this tool is preferred, and even clarifies how to interpret an empty match list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![OpenInsurance MCP server](https://glama.ai/mcp/servers/sluyasu/OpenInsurance/badges/card.svg)](https://glama.ai/mcp/servers/sluyasu/OpenInsurance)

Score Badge

Copy to your README.md:

[![OpenInsurance MCP server](https://glama.ai/mcp/servers/sluyasu/OpenInsurance/badges/score.svg)](https://glama.ai/mcp/servers/sluyasu/OpenInsurance)

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/sluyasu/OpenInsurance'

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