Skala — Legal Platform for Startups
Server Details
Incorporate globally, manage fundraising, corporate services, and more.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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 3.8/5 across 8 of 8 tools scored.
Most tools have distinct purposes targeting specific resources like companies, services, documents, or support. However, get_available_companies_for_registration and get_users_companies could cause minor confusion as both relate to company lists, though the former is for registration options and the latter for user-owned companies. Descriptions help clarify, but some overlap exists.
All tool names follow a consistent verb_noun pattern using snake_case, starting with 'get_' for retrieval tools and 'submit_' for action tools. This predictability makes it easy for agents to understand and select tools based on naming conventions.
With 8 tools, the count is well-scoped for a legal platform server, covering key areas like company management, services, documents, resources, tasks, and support. Each tool earns its place without feeling excessive or insufficient for the domain.
The tool surface provides good retrieval coverage for companies, services, documents, and tasks, but lacks action-oriented tools like creating companies, generating documents, or updating tasks. This creates notable gaps in CRUD/lifecycle operations, as agents can retrieve information but cannot perform core platform actions without workarounds.
Available Tools
8 toolsget_available_companies_for_registrationGet available company types for registrationBRead-onlyIdempotentInspect
Get the list of company types available for registration on the platform.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds no behavioral traits beyond this, such as rate limits or response format details, but it doesn't contradict the annotations, so it meets the baseline for adding minimal context.
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, clear sentence that directly states the tool's purpose without any wasted words. It's front-loaded and efficiently conveys the essential information, making it highly concise and well-structured.
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 (0 parameters, annotations provided, no output schema), the description is adequate but minimal. It covers the basic purpose but lacks details on when to use it or what the output entails, which could be helpful for an agent despite the annotations.
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 parameters and 100% schema description coverage, the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no inputs are required, so it compensates adequately, earning a high score for this simple case.
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 verb 'Get' and the resource 'list of company types available for registration on the platform', making the purpose understandable. It doesn't explicitly distinguish from sibling tools like 'get_available_corporate_services', which could be similar, so it doesn't reach the highest score for sibling differentiation.
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 no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, such as when to choose this over 'get_company_info_by_id' or other sibling tools, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_available_corporate_servicesGet available corporate servicesARead-onlyIdempotentInspect
Get corporate services available on the platform — including DBA, name changes, filings, compliance, registered agent, and other company-related services. Always check this when the user asks about any service for their company.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds value by specifying the scope ('corporate services available on the platform') and examples, but doesn't disclose additional behavioral traits like response format, rate limits, or authentication needs beyond what annotations provide.
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 core purpose in the first sentence, followed by a specific usage guideline. Both sentences earn their place by adding distinct value—no wasted words or 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?
Given the tool's simplicity (0 parameters, no output schema) and rich annotations (readOnlyHint, openWorldHint, idempotentHint), the description is reasonably complete. It covers purpose and usage well, though it could benefit from mentioning the response format or data structure since no output schema is provided.
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 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters, as none exist, and instead focuses on the tool's purpose and usage 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 verb 'Get' and resource 'corporate services available on the platform' with specific examples (DBA, name changes, filings, etc.), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_available_companies_for_registration' or 'get_useful_resources' beyond mentioning 'company-related services'.
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 explicit usage guidance: 'Always check this when the user asks about any service for their company.' This clearly indicates when to use this tool versus alternatives, offering a specific trigger condition for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_available_doc_gensGet available document templatesARead-onlyIdempotentInspect
Get the list of legal document templates available for generation on the platform (e.g. NDA, employment agreement, stock purchase agreement). For corporate services like 83(b) filing or registered agent, use get_available_corporate_services instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds context by specifying the scope of templates (legal documents) and examples, which helps the agent understand what kind of data to expect, though it doesn't detail behavioral traits like rate limits or response format beyond what annotations provide.
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 core purpose in the first sentence, followed by a clear usage guideline in the second sentence. Every sentence adds value without waste, making it efficient and well-structured for quick comprehension.
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 (0 parameters, no output schema) and rich annotations, the description is complete enough for the agent to use it correctly. It covers purpose, scope, and sibling differentiation, though it doesn't explain return values (e.g., format of the list), which is a minor gap since there's no output schema.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose and usage without redundant parameter info, earning a high score for not adding unnecessary details.
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 specific verb ('Get') and resource ('list of legal document templates available for generation'), providing concrete examples (NDA, employment agreement, stock purchase agreement). It explicitly distinguishes this tool from its sibling 'get_available_corporate_services' by specifying the type of templates it returns versus corporate services.
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 explicit guidance on when to use this tool versus alternatives: it specifies to use this tool for legal document templates and to use 'get_available_corporate_services' for corporate services like 83(b) filing or registered agent. This clear distinction helps the agent choose correctly between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_company_info_by_idGet company info by IDBRead-onlyIdempotentInspect
Get information about the user's company by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| company_id | Yes | Company ID on the platform. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds minimal context beyond this, specifying it retrieves information by ID but not detailing return format, error handling, or authentication needs. It doesn't contradict annotations, so a baseline 3 is appropriate.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
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 low complexity (single parameter, read-only operation) and rich annotations, the description is minimally adequate. However, without an output schema, it doesn't explain return values or potential errors, leaving some gaps for an agent to infer behavior.
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%, with the parameter 'company_id' fully documented in the schema. The description mentions 'by its ID', aligning with the schema but not adding extra meaning like ID format or examples. Baseline 3 is correct as the schema handles parameter documentation.
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 verb ('Get information') and resource ('about the user's company by its ID'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_users_companies', which might retrieve a list rather than specific details by ID.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a valid company ID, or compare it to siblings like 'get_users_companies' for broader queries. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_useful_resourcesGet useful resourcesBRead-onlyIdempotentInspect
Get a list of useful resources: guides, references, and instructional materials for legal topics and Skala platform usage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=false, and idempotentHint=true. The description adds that this returns 'a list' and specifies content types (guides, references, instructional materials) and domains (legal topics, Skala platform usage), which provides useful context beyond the annotations. However, it doesn't describe behavioral details like pagination, sorting, filtering capabilities, or response 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 a single, efficient sentence that front-loads the core purpose ('Get a list of useful resources') followed by specific content and domain details. Every word contributes meaning without redundancy or unnecessary elaboration.
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 tool with good annotations, the description provides adequate context about what resources are returned. However, without an output schema, it doesn't describe the structure of the returned list (e.g., format, fields, organization), which would help the agent understand how to process the results. The annotations cover safety and idempotency, but the description could better explain the scope of 'useful resources.'
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 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema fully documents the empty input structure. No additional parameter information is needed or provided.
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: 'Get a list of useful resources' with specific content types (guides, references, instructional materials) and domains (legal topics, Skala platform usage). It distinguishes from siblings by focusing on resources rather than companies, services, documents, or support requests. However, it doesn't explicitly contrast with similarly-named tools since none exist in the sibling list.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or suggest when other tools might be more appropriate. The agent must infer usage from the purpose alone without explicit contextual boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_users_companiesGet user's companiesBRead-onlyIdempotentInspect
Get the user's companies on the platform.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover key traits (read-only, non-open-world, idempotent), so the bar is lower. The description adds value by specifying 'user's companies,' implying personalization and authentication needs, which annotations don't address. It doesn't contradict annotations, and provides useful context beyond 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 a single, efficient sentence that front-loads the core purpose without unnecessary details. It earns its place by clearly stating what the tool does, making it appropriately sized and well-structured.
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 low complexity (0 parameters, no output schema) and rich annotations, the description is adequate but has gaps. It lacks details on output format, error handling, or authentication requirements, which could help the agent despite the annotations covering safety aspects.
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 parameters and 100% schema coverage, the baseline is 4. The description doesn't need to explain parameters, and it appropriately avoids redundant information, focusing on the tool's purpose instead.
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 'Get the user's companies on the platform' clearly states the action (get) and resource (user's companies), but it's vague about what 'companies' means in this context. It doesn't distinguish this tool from sibling tools like 'get_company_info_by_id' or 'get_available_companies_for_registration', leaving ambiguity about scope and differentiation.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., user authentication), or exclusions, and fails to reference sibling tools for comparison, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_users_tasks_and_deadlinesGet user's tasks and deadlinesBRead-onlyIdempotentInspect
Get the list of user's tasks and deadlines.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | Yes | Maximum number of items to return (default 10, max 50). | |
| cursor | Yes | Pagination cursor — pass the value from the previous response to get the next page. Null or omit for the first page. | |
| company_id | Yes | Optional company ID to filter tasks by a specific company. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only, non-open-world, idempotent operation, which covers key behavioral traits. The description adds no additional context about what 'tasks and deadlines' entail, potential rate limits, authentication needs, or response format, but it doesn't contradict the annotations either.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and appropriately sized for a straightforward retrieval tool.
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 annotations cover safety and idempotency, and the schema fully documents parameters, the description provides adequate context for a read operation. However, without an output schema, it doesn't explain what the returned 'list of tasks and deadlines' looks like, leaving a gap in understanding the response structure.
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 description coverage, the input schema fully documents all three parameters (company_id, cursor, limit) with clear descriptions. The description adds no parameter-specific information beyond what's in the schema, meeting the baseline for high schema coverage.
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 ('Get') and resource ('list of user's tasks and deadlines'), making it immediately understandable. However, it doesn't distinguish this tool from potential sibling tools that might also retrieve task-related data, as none of the listed siblings appear to overlap directly with this functionality.
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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or exclusions, leaving the agent to infer usage solely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_support_requestSubmit a support requestAInspect
Submit a support request to the Skala team on behalf of the user. Call this when the user needs human assistance that AI cannot provide, the question is too complex or high-risk, or the user explicitly asks for human support. IMPORTANT: Always confirm with the user before calling — describe what you will submit and ask for their approval. Before calling, compile the issue from conversation context into the description.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | User email for receiving the support response. Required for users without a linked Skala account — ask for it before calling. Null for linked users (Skala already has their email). | ||
| subject | Yes | Short one-line summary of the support issue. | |
| description | Yes | Detailed description compiled from conversation context: what the user needs, what was tried, relevant entities. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-readOnly, non-destructive operation, which aligns with the description's 'submit' action. The description adds valuable behavioral context not covered by annotations: the requirement for user confirmation, the need to compile context into the description, and the email handling logic for linked vs. unlinked users.
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 efficiently structured with three focused sentences: purpose, usage criteria, and procedural requirements. Every sentence adds essential information without redundancy, making it easy to parse and apply.
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 submission tool with no output schema, the description provides complete contextual guidance: clear purpose, explicit usage rules, procedural steps (confirmation, context compilation), and parameter handling logic. It compensates well for the lack of output schema with actionable instructions.
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%, providing full parameter documentation. The description adds minimal parameter-specific semantics beyond the schema, mainly reinforcing the 'description' parameter's context compilation requirement. Baseline 3 is appropriate given the comprehensive 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 the action ('Submit a support request') and the target ('to the Skala team on behalf of the user'), distinguishing it from sibling tools which are all getters. It specifies the tool's role in handling human assistance needs beyond AI capabilities.
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 on when to use ('when the user needs human assistance that AI cannot provide, the question is too complex or high-risk, or the user explicitly asks for human support') and includes mandatory prerequisites ('Always confirm with the user before calling — describe what you will submit and ask for their approval').
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!