kansei-mcp-server
Server Details
Local-first MCP navigator for AI agents. 11,000+ services, 200 recipes, 89-97% token savings.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- kansei-link/kansei-mcp-server
- GitHub Stars
- 1
- Server Listing
- KanseiLink MCP Server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 5 of 5 tools scored. Lowest: 3.5/5.
Each tool has a distinct purpose: search_services for discovery, lookup for pre-use info, analyze for analytics, inspect for admin tasks, and report for feedback. No two tools overlap in functionality.
All tool names are single verbs (analyze, inspect, lookup, report, search_services) following a consistent pattern. No mixed conventions.
With 5 tools covering search, lookup, analytics, admin inspection, and reporting, the count is well-scoped for the server's purpose. Each tool earns its place.
The tools cover search, lookup, analysis, admin, and reporting, but lack an 'execute' tool for actually using the service integration. The standard flow mentions execution as a step, yet no tool is provided for it, creating a notable gap.
Available Tools
5 toolsanalyzeAnalyzeARead-onlyInspect
Analytics and reporting. Analyze token savings, audit agent costs, generate AEO reports and articles.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Explicit mode selection. Auto-detected from params if omitted: category → token_savings, cost_service_id → cost, aeo_service_id → aeo_report, article_type/target_keyword → aeo_article. | |
| task | No | [token_savings] Optional task context (e.g., 'create invoice in freee') to tailor the analysis. | |
| model | No | [cost] Model name hint for cost mode detection. | |
| top_n | No | [cost] Max recommendations to return (default: 10, max 50). Sorted by priority (high first) then by monthly_savings_usd desc. | |
| format | No | [aeo_article] Output format: 'markdown' for blog/press, 'json' for API/embed. | |
| period | No | [cost] Period hint for cost mode detection. | |
| quarter | No | [aeo_article] Report period label (e.g., 'Q2 2026', '2026年上半期'). | |
| category | No | [token_savings/aeo_report] Filter by category (e.g., 'accounting', 'hr', 'crm'). Triggers token_savings when used alone. | |
| services | No | [token_savings] List of service IDs to analyze (e.g., ['freee', 'kintone']). Omit to analyze the top 10 most-used services. | |
| aeo_top_n | No | [aeo_report] Number of top services to return (default: 20). | |
| categories | No | [aeo_article] Focus categories for deep-dive sections. Omit for default set. | |
| period_days | No | [cost] Analysis period in days (default: 30). | |
| article_type | No | [aeo_article] Article type hint. Triggers aeo_article mode when present. | |
| min_priority | No | [cost] Minimum priority level to include. 'high' returns only impactful recs; 'low' returns everything. | |
| article_top_n | No | [aeo_article] Number of services in the overall ranking table (default: 20). | |
| aeo_service_id | No | [aeo_report] Filter by service ID. Triggers aeo_report mode when present (without article params). | |
| target_keyword | No | [aeo_article] Target keyword for the article. Triggers aeo_article mode when present. | |
| cost_service_id | No | [cost] Audit a specific service, or omit for all services. | |
| include_recommendations | No | [aeo_report] Include improvement recommendations per service (default: true). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's read-only nature is implied. The description adds no additional behavioral context (e.g., auth needs, rate limits), meeting the baseline but not exceeding it.
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 that front-loads the core purpose ('Analytics and reporting') and lists specific capabilities. Every word earns its place 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?
Despite the tool's 19 parameters, the schema fully documents each parameter with descriptions, so the brief high-level description suffices for general understanding. It captures the main modes but lacks a structured overview.
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 100%, so parameters are fully documented in the schema. The description adds no extra meaning to the parameters, resulting in a baseline score of 3.
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: analytics and reporting, specifically token savings analysis, cost auditing, and AEO report/article generation. This distinguishes it from siblings like inspect, lookup, and report.
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?
No guidance on when to use this tool vs alternatives. No explicit conditions or exclusions are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inspectInspectAInspect
Internal admin tool for colony health. Inspect anomalies, manage update proposals, take snapshots, and evaluate MCP design patterns. Modes: queue (view anomalies), submit (verify anomaly), check_updates (service changelog), propose (PR-model data update), review (approve/reject proposal), pending (view proposal queue), snapshot (capture daily metrics), evaluate (rate API design quality). Mode is auto-detected from params or set explicitly.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Explicit mode override. Auto-detected from params if omitted. | |
| field | No | [propose] Single field to update (shorthand). Allowed: description, category, tags, mcp_endpoint, mcp_status, api_url, api_auth_method, namespace. | |
| reason | No | [propose] Why this change is needed | |
| changes | No | [propose] Object of field->new_value pairs (alternative to field+new_value) | |
| verdict | No | [submit] Your finding: confirmed, false_alarm, resolved, or partially_resolved | |
| agent_id | No | [propose/review] Agent identifier for attribution | |
| approved | No | [review] true = approve, false = reject | |
| findings | No | [submit] What you found during inspection (PII auto-masked) | |
| reviewer | No | [review] Who is reviewing (default: michie) | |
| new_value | No | [propose] New value for the field (used with field shorthand) | |
| update_id | No | [review] Proposal ID to review. With approved → review mode. | |
| since_days | No | [check_updates] How many days back to look (default: 30) | |
| change_type | No | [propose] Type of change (default: update) | |
| queue_limit | No | [queue] Max results (default: 10) | |
| review_note | No | [review] Optional review comment | |
| evidence_url | No | [propose] URL to source (API docs, changelog) | |
| queue_status | No | [queue] Filter by status (default: open) | |
| inspection_id | No | [submit/queue] Inspection ID. With verdict → submit mode. Alone → queue lookup. | |
| pending_limit | No | [pending] Max results (default: 20) | |
| snapshot_date | No | [snapshot] Date to snapshot (YYYY-MM-DD, default: today) | |
| evaluate_notes | No | [evaluate] Free-text notes on design strengths/weaknesses | |
| pending_status | No | [pending] Filter by status. Triggers pending mode when present. | |
| queue_severity | No | [queue] Filter by severity (default: all) | |
| check_service_id | No | [check_updates] Service name or ID to check for changes. Triggers check_updates mode. | |
| queue_service_id | No | [queue] Filter by specific service ID | |
| workaround_works | No | [submit] Did the tested workaround work? | |
| api_quality_score | No | [evaluate] API design quality: RESTful conventions, naming, status codes (0.0-1.0) | |
| tested_workaround | No | [submit] Workaround you tested, if any | |
| pending_service_id | No | [pending] Filter by service ID | |
| propose_service_id | No | [propose] Service ID to propose changes for | |
| error_clarity_score | No | [evaluate] Error response quality: clear codes, actionable messages (0.0-1.0) | |
| evaluate_service_id | No | [evaluate] Service to evaluate. Triggers evaluate mode. | |
| snapshot_service_id | No | [snapshot] Service to snapshot. Triggers snapshot mode. Omit value to snapshot ALL. | |
| auth_stability_score | No | [evaluate] Auth reliability: token refresh, expiry handling, OAuth flow (0.0-1.0) | |
| doc_completeness_score | No | [evaluate] Documentation quality: completeness, accuracy, examples (0.0-1.0) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutating and non-idempotent behavior. The description adds that it is an internal admin tool and lists actions like submit, propose, review, which imply mutations. It does not detail side effects, authorization, or rate limits beyond 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 a single paragraph listing modes efficiently. It is not overly long given the 35 parameters, though a more structured format (e.g., bullets) could improve readability.
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?
With 35 parameters, no output schema, and no required params, the description summarizes overall tool behavior and modes well. However, it lacks details about output format, return values, or post-action effects, which would be helpful.
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 100% description coverage. The description adds value by explaining mode auto-detection and grouping which parameters belong to which mode, providing context beyond the schema's individual parameter descriptions.
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 an internal admin tool for colony health with specific modes like inspect anomalies, manage proposals, take snapshots, evaluate design patterns. It distinguishes purpose from sibling tools like analyze, lookup, report, search_services by listing unique modes, but does not explicitly differentiate.
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 lists many modes and mentions auto-detection from params, implying when to use each mode. However, it lacks explicit guidance on when to use this tool versus siblings, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookupLookupARead-onlyInspect
Get everything you need about a service before using it. Default: tips (auth setup, pitfalls, workarounds). Add detail: true for full connection guide, insights: true for usage data. Pass goal: 'workflow description' to find multi-service recipes. This is step 2 of the standard KanseiLink flow: search_services → lookup → (execute) → report.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | Workflow goal — triggers recipe mode (e.g., 'onboard employee') | |
| mode | No | Explicit mode override | |
| detail | No | Get full connection guide (auth, endpoints, rate limits) | |
| period | No | Time period — triggers history mode | |
| service | No | Fuzzy service name — triggers combinations mode | |
| insights | No | Get aggregated usage data (success rate, trends, errors) | |
| services | No | Your available service IDs — for recipe coverage calculation | |
| service_id | No | Service ID (from search_services) | |
| compare_with | No | Competitor service_id for comparison — triggers history mode | |
| feedback_type | No | [feedback] Filter by feedback type | |
| feedback_limit | No | [feedback] Max results (default 20) | |
| feedback_status | No | [feedback] Filter by status. Triggers feedback mode when present. | |
| voice_agent_type | No | [voices] Filter by agent type (claude, gpt, gemini) | |
| voice_question_filter | No | [voices] Filter by question_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, establishing read-only nature. The description reinforces this by focusing on retrieving information. It adds context on default tips and specific parameter behaviors (detail, insights, goal) without contradicting annotations. Minor gap: no mention of rate limits or result format.
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 four sentences long, each serving a clear purpose: purpose statement, default behavior, advanced parameter use, and flow positioning. It is front-loaded with the most critical information and contains no superfluous words.
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 14 parameters and no output schema, the description covers core usage (tips, detail, insights, goal) but omits details on parameters like period, compare_with, service, feedback, and voices. The return format is not described, leaving some gaps. However, the annotations compensate for behavioral safety.
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 100% schema coverage, baseline is 3. The description adds narrative context explaining how parameters like detail, insights, and goal modify behavior (e.g., 'Add detail: true for full connection guide'). This goes beyond schema descriptions by tying parameters to usage scenarios, though not all 14 parameters are explicitly covered.
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 as 'Get everything you need about a service before using it', using a specific verb and resource. It distinguishes itself from siblings like search_services (step 1) and execute/report by positioning itself as step 2 in the KanseiLink flow, making the role 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 provides context on when to use (before using a service) and how it fits in the flow. It explains default behavior and parameter effects (detail, insights, goal). However, it does not explicitly state when not to use it or list alternatives, which slightly reduces clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reportReportAInspect
Contribute data back to the KanseiLink community. Report success/failure after using a service (5 seconds, helps everyone), submit feedback, record API change events, or share your qualitative experience. PII is auto-masked. This is step 4 of the standard flow: search_services → lookup → (execute) → report.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | [feedback] Your feedback in detail. Write freely. | |
| mode | No | Explicit mode selection. Auto-detected from params if omitted: success → outcome, question_id → voice, event_type → event, subject+body → feedback. | |
| title | No | [event] Short event title (e.g., 'freee API v3 deprecation'). | |
| context | No | [outcome] Additional context about the usage (PII will be auto-masked). | |
| subject | No | [feedback] Short summary of your feedback (1 line). | |
| success | No | [outcome] Whether the operation succeeded. | |
| agent_id | No | Your agent identifier (optional, for follow-up). Used in feedback and voice modes. | |
| cost_usd | No | [outcome] Actual cost in USD (estimated from tokens if omitted). | |
| is_retry | No | [outcome] Whether this is a retry of a previously failed call. | |
| priority | No | [feedback] How important: low, normal, high, critical. Default: normal. | |
| task_type | No | [outcome] Operation performed (e.g., 'create_invoice', 'search_contacts'). | |
| agent_type | No | Agent platform type (claude, gpt, gemini, copilot, llama, deepseek, other). Used in outcome mode (auto-inferred from model_name if omitted) and voice mode. | |
| confidence | No | [voice] How confident are you in this assessment? high, medium, low. | |
| error_type | No | [outcome] Error category if failed (e.g., 'auth_error', 'timeout', 'rate_limit', 'schema_mismatch'). | |
| event_date | No | [event] When the event occurred or takes effect (YYYY-MM-DD). | |
| event_type | No | [event] Category: api_change, api_deprecation, law_amendment, pricing_change, outage, security_incident, feature_launch, competitor_move, mcp_update, other. | |
| latency_ms | No | [outcome] Response time in milliseconds. | |
| model_name | No | [outcome] LLM model used (e.g., 'claude-sonnet-4', 'gpt-4o'). | |
| service_id | No | Service ID. Required for outcome and voice modes. Optional for feedback and event. | |
| workaround | No | [outcome] How you resolved the issue, if any. Helps future agents. | |
| description | No | [event] Details about the event and expected impact. | |
| question_id | No | [voice] Which question to answer: selection_criteria, would_recommend, biggest_frustration, best_feature, switching_likelihood, auth_experience, doc_quality, error_handling, compared_to_competitor, mcp_readiness, free_voice. | |
| input_tokens | No | [outcome] Input/prompt token count. | |
| feedback_type | No | [feedback] Type of feedback: suggestion, missing_data, correction, feature_request, workaround_tip, bug_report, praise, other. | |
| output_tokens | No | [outcome] Output/completion token count. | |
| response_text | No | [voice] Your honest answer in your own words. | |
| estimated_users | No | [outcome] Approximate number of end-users your agent serves. | |
| impact_expected | No | [event] Expected impact: positive, negative, neutral, unknown. | |
| response_choice | No | [voice] Quick rating where applicable (e.g., 'strongly_yes', 'excellent', 'ready'). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is neither read-only nor idempotent. The description adds value by specifying that 'PII is auto-masked' and detailing the side effects of submitting data. Since annotations are minimal (only two booleans), the description adequately carries the behavioral transparency burden.
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 plus a phrase, front-loading the main purpose and providing essential context. Every sentence is informative and there is 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?
Despite 29 parameters and no output schema, the description covers the tool's role in the workflow, explains mode selection, mentions PII handling, and references related tools. This is sufficient for an agent to decide when and how to invoke the tool.
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 provides 100% coverage with descriptions for all 29 parameters. The description adds context by grouping parameters by mode (e.g., '[outcome]', '[event]') and explaining auto-detection logic, which helps agents understand how to construct requests.
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: 'Contribute data back to the KanseiLink community' and lists specific actions (report success/failure, submit feedback, record events, share experience). It distinguishes from sibling tools like search_services, which focus on retrieving data.
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 explicitly places the tool as 'step 4 of the standard flow: search_services → lookup → (execute) → report', providing clear context for when to use it. It also explains auto-detection of modes and outlines prerequisites for different report types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_servicesSearch ServicesARead-onlyInspect
Before attempting ANY SaaS API integration, call this tool. Agents waste 3-5x more tokens on trial-and-error with stale training data — this returns verified, current service evaluations so you succeed on the first try. If the user mentions ANY SaaS service (freee, SmartHR, kintone, Slack, Notion, MoneyForward...) or says 'use kanseilink', always call this. Covers 900+ services with real agent success data. Strongest in Japanese SaaS with growing global coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default: 5) | |
| intent | Yes | What you want to accomplish (e.g., 'send invoice', 'manage employees', 'track attendance') | |
| compact | No | Return minimal fields for token efficiency. Default: false | |
| category | No | Filter by category: crm, project_management, communication, accounting, hr, ecommerce, legal, marketing, groupware, productivity, storage, support, payment, logistics, reservation, data_integration, bi_analytics, security, developer_tools, ai_ml, database, devops, design | |
| agent_ready | No | Filter by agent readiness: 'verified' (🟢 battle-tested, success rate ≥80%), 'connectable' (🟡 API/MCP exists but unproven), 'info_only' (⚪ no API). Omit for all. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true. The description adds valuable behavioral context: returns 'verified, current service evaluations', covers 900+ services, strong in Japanese SaaS, and notes token efficiency. No contradictions.
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 front-loaded with the critical directive. Some slight excess ('Agents waste 3-5x more tokens...') but overall efficient. Could be trimmed slightly without losing value.
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?
No output schema, but the description covers what to expect: verified evaluations, success data, coverage scope. Lacks exact field names, but the compact parameter allows minimal fields. Sufficient for a search tool.
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 100%, so baseline is 3. The description does not add new meaning to individual parameters beyond the schema, but the general context of 'real agent success data' indirectly enriches the intent parameter. Adequate but not exceptional.
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 states a specific verb+resource ('search services') with a clear purpose: to return verified, current service evaluations before API integration. It distinguishes from sibling tools by emphasizing its role as a pre-integration search.
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 tells when to use ('before ANY SaaS API integration', 'if user mentions any SaaS service... always call this') and implies when not to (for other tasks like analyze or inspect). Provides clear context for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.