Segfy, multi-quote and management platform for insurance brokers. Connect your account with your Seg
MCP.AI for IDE agents (Cursor, etc.): log in in the browser, copy the access token. Best: add it to this server's config as a header Authorization: Bearer <token> for a permanent, non-expiring connection. Or paste it here for a session-only login: call with { token: "" } after the user pastes, or with no args to get the link.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal idempotent and non-destructive. The description adds that token login is session-only and config is permanent, which is useful. However, it doesn't disclose side effects like overwriting existing sessions or authentication state checking, which would be helpful. Contradicts nothing.
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?
Information is accurate but presented as a run-on paragraph with colons and semicolons. It could be broken into clearer steps or bullets. No wasted sentences, but structure could be improved for scannability.
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 single-parameter tool with no output schema, it covers the essential use cases: both invocation modes, the config alternative, and session vs permanent behavior. Minor gaps like error handling or post-auth verification exist but are not critical.
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?
Schema has zero descriptions, so the description carries the burden. It thoroughly explains the 'token' parameter, including the JWT format and that omitting it returns a link. This compensates well for the sparse 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 states this tool is for authentication via browser login and token exchange. It explains the two invocation modes (no args for link, or token for session login). Though it doesn't explicitly distinguish from sibling 'connect', the purpose is specific and actionable.
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?
Explicitly contrasts session-only login (passing token) with permanent config via header, and explains when to call with no args. It doesn't name alternatives among siblings but provides clear contextual guidance for the two usage patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns connection status and URLs. When all providers are connected, returns authenticated:true and empty pending[]. When credentials are missing, returns connect_url for the toolkit and per-install URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds useful behavioral detail about conditional output: authenticated:true with empty pending[] when connected, and connect_url with per-install URLs when credentials are missing. This goes beyond the annotations without contradicting them.
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 two sentences and front-loaded with the tool's purpose. Every sentence adds distinct information about the return value and conditional behavior, with no redundancy.
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 zero-parameter, read-only status tool with strong annotations, the description is complete. It covers both main output states and the relevant URL fields, and no output schema is needed given the low complexity and direct explanation.
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 input schema has zero parameters and the description covers the full schema. With no params, the baseline is 4; the description adds no parameter semantics because none exist, but it compensates by explaining observable return states.
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 states the tool returns connection status and URLs, with a specific verb and resource. It differentiates from siblings like authenticate and toolkit_info by focusing on connection state and URL responses.
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 description gives clear context on when to use the tool: to check connection status and retrieve URLs. It explains conditional behavior when providers are connected versus credentials missing, but does not explicitly mention when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them. Covers capability requests like "find an MCP that does X", "consulta um CPF", "is there a tool for Y". Core flow: action=search discovers MCPs by intent → describe returns one MCP's full profile (every tool with its id + params, pricing, auth) so you pick the right tool_id → invoke RUNS that tool. KEY: invoke works even when the MCP is NOT installed — it runs the tool pontualmente (one-off), without adding the MCP to the toolkit and without bloating the tool list. If the MCP needs a credential/login, invoke returns a connect link; if it is paid and the wallet is empty, invoke returns a checkout/top-up link (the user opens it, then you retry). Use install only to make an MCP PERMANENT in the active toolkit (its tools then show up natively in future sessions); prefer invoke for a single/occasional use. list_tools lists what is callable right now. subscribe/cancel handle per-MCP billing; report_bug sends feedback; request_mcp asks us to build a NEW MCP when nothing fits. Search/describe flag installed_in_toolkit vs installed_in_workspace. Writes (install/uninstall/subscribe/cancel and the one-off install behind invoke) require workspace owner/admin. It also carries the mcp.ai PROMPT LIBRARY, which is about ready-made prompt TEXT rather than MCPs: search_prompts finds one, get_prompt returns its full text with {{variables}} filled, and publish_prompt saves a prompt and returns a shareable mcp.ai/p/ link that opens without login.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| action | No | search | |
| mcp_id | No | ||
| message | No | ||
| tool_id | No | ||
| arguments | No | {} | |
| immediate | No | ||
| tier_slug | No | ||
| prompt_body | No | ||
| prompt_slug | No | ||
| prompt_tool | No | ||
| prompt_vars | No | {} | |
| conversation | No | [] | |
| prompt_title | No | ||
| request_name | No | ||
| cancel_reason | No | ||
| cancel_comment | No | ||
| prompt_targets | No | ||
| report_context | No | ||
| prompt_category | No | ||
| request_details | No | ||
| prompt_description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-read-only, open-world, non-idempotent, non-destructive. The description adds rich behavioral context: invoke works even if the MCP isn't installed, runs pontualmente without bloating tool list, returns connect/checkout links for auth/payment, and requires owner/admin for writes. No contradictions with annotations.
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 long but well-structured, flowing from the main purpose to the core flow, then key distinctions (invoke vs install), permissions, and the prompt library. Each sentence adds value, but it is dense and might overwhelm agents; still, it is front-loaded and organized.
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 complex tool with 23 parameters, no output schema, and many use cases, the description covers the entire workflow, auth/payment links, permission requirements, the distinction between installed and one-off execution, and the prompt library. It is complete enough for an agent to decide when and how to use it.
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?
With 0% schema description coverage, the description compensates by explaining the action enum in detail and implicitly defining mcp_id, tool_id, arguments, query, limit, prompt_* fields, etc. However, not every parameter is explicitly described (e.g., immediate, tier_slug, conversation, report_context), though defaults and enums help. Slight gap but substantial added meaning.
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 states it is the official mcp.ai marketplace catalog and execution engine, covering both MCP discovery and running, plus the prompt library. It distinguishes from siblings by enumerating its specific actions (search, describe, invoke, install, etc.) and explaining the core flow.
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?
Explicit guidance is provided: prefer invoke for one-off use, use install only for permanent inclusion, list_tools shows currently callable tools, and the prompt library actions are separated. It also notes write actions require owner/admin, and when auth or payment is needed the tool returns links to resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report a bug, missing feature, or send feedback. Include the conversation array with recent messages for reproduction.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | ||
| message | Yes | ||
| conversation | No | [] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about including the conversation for reproduction, but it does not explain what happens after the report is submitted, whether it creates an external ticket, or if there are any side effects beyond the idempotent submission.
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 two clear sentences with no wasted words. It front-loads the main purpose and then provides a practical instruction. It is concise, though it could have used additional space to clarify parameters without becoming bloated.
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 feedback/report tool, the description covers the core intent and one important input detail. However, it leaves the 'message' and 'context' parameters unexplained, and there is no mention of the expected response. Given the absence of an output schema and 0% schema description coverage, this is only minimally sufficient.
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?
Schema description coverage is 0%, so the description must compensate. It explains the purpose of the conversation parameter ("Include the conversation array with recent messages for reproduction"), but it does not clarify the required 'message' parameter or the optional 'context' parameter. This leaves significant ambiguity for the agent, especially for 'context'.
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 states the tool's purpose with a specific verb: "Report a bug, missing feature, or send feedback." This distinguishes it from the sibling tools, which are unrelated to bug reporting or feedback.
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 description gives clear context for when to use the tool: whenever the user needs to report a bug, missing feature, or provide feedback. It also includes an explicit instruction to include the conversation array for reproduction. It does not mention exclusions or alternatives, but the purpose statement effectively frames the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Conta Segfy conectada: e-mail e identificador do corretor. Confirma qual login está ativo. Use para validar a conexão antes das demais operações.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds that it returns email and broker ID and confirms active login, which is useful. It does not detail what happens if no connection exists, but annotations are strong.
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 a single sentence with no fluff, front-loaded with key information. Every word earns its place.
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 parameterless tool with strong annotations and no output schema, the description is complete enough. It covers purpose and usage guidance; not much else is needed.
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 tool has zero parameters, and schema coverage is 100%, so there is nothing to explain over the schema. Baseline 4 is appropriate.
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 states it lists the connected Segfy account (email and broker identifier) and confirms which login is active. It distinguishes itself from siblings by specifying its role in validating the connection, though it could explicitly mention that it does not perform authentication itself (unlike 'authenticate' or 'connect').
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?
It explicitly recommends using this tool to validate the connection before other operations, which gives clear context for when to use it. It does not explicitly exclude cases or name alternatives, but the recommendation is sufficient given the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the current MCP platform and adapter versions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description is not responsible for conveying that safety profile. The description adds the scope of the version info but does not disclose return format or whether it might return structured vs. plain text, which would be helpful given no output schema.
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 a single sentence, front-loaded with the action, and contains no filler or redundant phrases. Every word contributes to clarity.
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?
Given the tool's simplicity and the absence of an output schema, the description conveys the key information an agent needs: what information is returned. It does not list possible version string formats or adapters included, but for this narrow read-only tool, the description is sufficiently complete.
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 tool has zero parameters, so the schema is complete and the description is not required to explain any parameter behavior. The baseline of 4 for no-parameter tools applies, with no deductions needed since the description says nothing misleading about inputs.
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 uses a specific verb ('Show') and names the exact resource being exposed ('current MCP platform and adapter versions'). It clearly distinguishes this tool from its siblings like authenticate, connect, and segfy_list_accounts, which serve entirely different purposes.
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 description implies when to use the tool (whenever the agent or user needs version information) but provides no explicit guidance about alternatives or situations where it should not be used. For a simple informational tool with no sibling doing similar work, this implied usage is minimally viable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current toolkit state: installed MCPs, their connection status, the accounts connected to each one, and how many catalog tools each exposes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds specific behavioral context by listing the exact data returned (installed MCPs, connection status, accounts, catalog counts), which goes beyond the annotations. It does not contradict annotations and provides useful output detail.
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 a single, focused sentence that immediately states the core function and lists the key data components. There is no redundancy, and it efficiently conveys everything necessary for a simple tool. Front-loaded with 'Returns the current toolkit state'.
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?
Given the tool's simplicity (no parameters, no output schema, clear annotations), the description fully covers what the tool does and what it returns. It explains the return content adequately (installed MCPs, connection status, accounts, catalog counts), so an agent can predict the tool's behavior and output without additional info.
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 tool has zero parameters, so the schema provides no parameter information. Per guidelines, with 0 params the baseline is 4. The description doesn't need to add parameter meaning, and it doesn't—it explains the purpose, which is sufficient for a parameterless tool.
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 states the tool's function: 'Returns the current toolkit state' and enumerates specific details (installed MCPs, connection status, accounts, catalog tool counts). It distinctly differentiates from siblings like 'show_version' by focusing on state rather than just version, making its purpose unambiguous.
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 description implies usage but does not explicitly state when to use it versus alternatives. It could have noted, e.g., 'Use this when you need an overview of the toolkit's components.' As a simple read-only tool, the context is implied, but there is no direct guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
No tool schema history has been recorded yet.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Agger, multi-quote and management platform for insurance brokers. Connect your account with your Agg
Live Nigerian insurance quotes across insurers, free policy check-up, and hosted checkout links.
Connect your SafraPay account to AI via Brazil's Open Finance: balances, statements, cards, investme
Connect your Porto Bank account to AI via Brazil's Open Finance: balances, statements, cards, invest
Add one secure layer between your agents and this server.
The tools are a mix of platform-level utilities (authenticate, connect, show_version, toolkit_info) and domain-specific ones (segfy_list_accounts, marketplace, report_bug). While marketplace is clearly the broad hub, there is overlap between connect and toolkit_info (both return connection status), and authenticate/connect have similar auth-related responsibility. The segfy_list_accounts is distinct but its purpose is narrow, and report_bug is separate but not confusing.
Names are a mix of single verbs (authenticate, connect), compound nouns (marketplace, toolkit_info), and snake_case with prefixes (segfy_list_accounts, show_version). There is no consistent pattern across the set; some use verbs, some use nouns, and one has a domain prefix. This makes the pattern unpredictable, though each name is readable.
Seven tools is a reasonable count, but the scope is broad: they span authentication, connection status, marketplace search/invoke, prompt library, bug reporting, and a single Segfy-specific operation. This breadth makes it feel slightly unfocused, but it is not excessive or trivial.
For a platform that manages MCPs, the marketplace tool covers search, describe, invoke, install, subscribe/cancel, prompts, and bug reporting, which is fairly complete. However, there is a notable gap: there is no explicit tool to uninstall or manage workspace settings beyond what's inside marketplace. Also, the Segfy-side is incomplete—only one operation (list accounts) without further actions, suggesting a shallow domain surface.