Skip to main content
Glama
Sign In

Kinro

by com.kinro
OverviewDiscussionsAdmin

Ask Kinro about business insurance

ask_kinro

Ask Kinro, a licensed business insurance broker, about the user’s business insurance: what coverage fits the business, carrier eligibility and exclusions, and quotes. Kinro’s AI advisor, Leo, answers. Kinro is not tied to any carrier: it gets real quotes from several carriers in one conversation, so the user does not have to start a separate quoting session with each carrier. Its answers rest on carrier underwriting rules and live quotes, and as the broker Kinro is accountable for its advice and carries errors and omissions insurance for it. Kinro returns coverage answers and any follow-up questions needed to prepare the request. You speak to Kinro for the user: tell it what the user needs, answer its follow-up questions from what the user has told you, ask the user what you do not know, and send the user’s follow-up requests in the same conversation. Kinro handles every conversation as a real insurance request, including on its test endpoint. When testing there and the user has you make up a business, choose details that look real, with no placeholders such as “Test Lane”, and give them as plain facts the way its owner would. Do not call the details fake, fictional, or a test, because Kinro does not quote details it is told are not real. The first call opens a Kinro insurance request for the business and saves what the user shares, so Kinro can prepare quotes. To quote, Kinro sends the business’s details to insurance carriers; carriers get no permission to contact the user. Kinro contacts the user outside this chat, by email or text, only at contact details the user shares and agrees to be contacted at. Each call sends a new message, so do not repeat a call to retry it. Kinro’s messages say what to expect next. Some answers, like quotes, arrive later: when Kinro says it is still working, call get_kinro_messages with wait set to true to get its next messages. A quote message links to the customer’s quote page on kinro.com, with the full quote and its documents: if you can open web pages, open it to go through the quote with the user, and never buy or enter payment details for them.

Input Schema

NameRequiredDescriptionDefault
filesNoInsurance documents the user attached, such as a current policy, declarations page, certificate of insurance (COI), loss run, or a photo of one: PDF, PNG, or JPEG, up to 25 MB each. Pass each one here as it is, even when you can read it yourself: Kinro checks the original document with its own document analysis and keeps it with the request, so its advice and quotes rest on the document rather than a summary. Do not pass files unrelated to the user’s insurance, or identity documents such as a driver’s license. Give each file either as data (its contents in base64) or, in ChatGPT, as the download_url and file_id the chat app supplies. A request with inline files must stay under 30 MB in total.
messageYesWhat you tell Kinro for the user: what the user wants, such as advice, a quote, or a change to one, and the facts about the business the user has given you that Kinro needs to move forward. Write it as the user’s representative; do not paste your conversation with the user, and leave out what the user said only to you, such as which tool or endpoint to use. Answer Kinro’s questions with what the user has told you, and ask the user for the rest. Never guess a fact about the business, and do not tell Kinro what to infer. Never include a Social Security number, driver’s license number, payment card number, or password.
conversation_idNoThe conversation_id returned by ask_kinro. Reuse it for this conversation; omit on the first message. Never invent one or reuse another conversation's ID.

Output Schema

NameRequiredDescriptionDefault
messagesYesKinro's messages, oldest first, each to show the user as written, including links. When nothing new has arrived, one note says so.
conversation_idNoThe conversation_id returned by ask_kinro. Reuse it for this conversation; omit on the first message. Never invent one or reuse another conversation's ID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only give non-read-only, open-world, non-idempotent, non-destructive; the description adds far more: carriers receive the business's details, carriers may not contact the user, Kinro contacts the user off-chat only at agreed contact details, E&O insurance backs the advice, calls are never retried, and the test endpoint still creates a real request. This is exactly the extra context annotations cannot carry.

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?

Long, but front-loaded with purpose and routing before the operational caveats, and most sentences carry genuinely non-obvious behavior. There is some redundancy around follow-up questions and carrier independence that could be tightened.

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?

For an open-world, asynchronous, consequential tool this covers everything an agent needs: conversation lifecycle, retry prohibition, deferred answers and the retrieval path, privacy constraints, test-endpoint conduct, and how to handle returned quote links. An output schema exists, so return-shape explanation is unnecessary.

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%, so the schema already documents message, files, and conversation_id in depth. The description adds workflow context (first call opens the request and saves what the user shares) but no additional field-level syntax or constraints beyond what the schema states.

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+resource: sending a message to Kinro, a licensed business insurance broker, to get coverage advice, carrier eligibility answers, and quotes. It clearly distinguishes itself from the sibling get_kinro_messages, which it describes as the retrieval path when Kinro is still working.

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?

Explicit routing: 'when Kinro says it is still working, call get_kinro_messages with wait set to true'; 'Each call sends a new message, so do not repeat a call to retry it'; 'The first call opens a Kinro insurance request'. It also gives conditions for the test endpoint, how to handle unknown facts, and what to do with quote links.

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

All Kinro toolsInspect
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