Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-sling Show me today's schedule for all users."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol (MCP) server for the Sling API - a comprehensive scheduling and workforce management platform.
Quick Start: New to this? See QUICK_START.md for a 5-minute setup guide!
This MCP server provides tools to interact with all major Sling API endpoints:
get_calendar - Retrieve calendar and shift data for users
create_shift - Create new shifts for employees
get_timesheets - View timesheet data and actual hours worked
update_timesheet - Modify timesheet entries
get_users - List all users in your organization
create_user - Add new users
update_user - Modify user information
get_organization - View organization details
get_organization_by_id - Get specific organization info
switch_organization - Switch between organizations
get_groups - List organizational groups
get_reports - Access various reports (labor, schedule, attendance)
create_sales_record - Record sales data for analytics
get_tags - Retrieve available tags for categorization
update_settings - Modify organization or user settings
sling_api_call - Make custom API calls to any Sling endpoint
Related MCP server: Officient MCP Server
Clone this repository:
git clone <repository-url>
cd mcp-slingInstall dependencies:
npm installBuild the project:
npm run buildGet your Sling authorization token:
IMPORTANT: Due to CAPTCHA requirements on the Sling login endpoint, you need to obtain your authorization token from your browser.
Follow the detailed guide: TOKEN_GUIDE.md
Create a .env file with your token:
cp .env.example .envEdit .env and add your token:
SLING_TOKEN=your-token-from-browser
SLING_SERVER=apiRecommended approach (avoids CAPTCHA):
SLING_TOKEN (required) - Your Sling authorization token from browser
See TOKEN_GUIDE.md for instructions
SLING_SERVER (optional) - API server to use (default: "api", use "test-api" for staging)
Alternative (requires CAPTCHA - not recommended):
SLING_EMAIL - Your Sling account email
SLING_PASSWORD - Your Sling account password
Note: Currently not working due to CAPTCHA requirement on /account/login endpoint
Add this to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
Recommended: Using token
{
"mcpServers": {
"sling": {
"command": "node",
"args": ["/absolute/path/to/mcp-sling/dist/index.js"],
"env": {
"SLING_TOKEN": "your-token-from-browser"
}
}
}
}Alternative: Using .env file
{
"mcpServers": {
"sling": {
"command": "node",
"args": ["/absolute/path/to/mcp-sling/dist/index.js"]
}
}
}(Requires .env file with SLING_TOKEN configured)
Once configured, you can use the Sling tools through Claude. Here are some example queries:
Can you get the list of all users in my Sling organization?Show me the calendar for user ID 12345 in organization 67890 for dates 2024-01-15Create a shift for user 12345 starting at 2024-01-20T09:00:00Z and ending at 2024-01-20T17:00:00Z for the "Cashier" positionGet the labor report for the period from 2024-01-01 to 2024-01-31Make a GET request to /custom/endpoint with params {"filter": "active"}This server handles authentication automatically using your configured credentials. The authentication flow:
On first request, the server logs in to Sling using your email/password
The authentication token is cached and reused for subsequent requests
If a token expires (401 error), the server automatically refreshes it
Tokens are typically valid for 1 hour
Note: The Sling API uses email/password authentication as documented in their official examples.
Important Update: As of November 2024, Sling has added CAPTCHA protection to the /account/login API endpoint. This means direct email/password authentication no longer works without solving a CAPTCHA challenge.
Solution: Use a pre-obtained authorization token from your browser instead. See TOKEN_GUIDE.md for detailed instructions.
Why this approach works:
Tokens obtained from browser sessions don't require CAPTCHA
Tokens typically remain valid for weeks or months
You only need to get a new token when it expires or you change your password
This is the recommended approach until Sling provides an alternative API authentication method
For detailed information about the Sling API endpoints and data formats, refer to:
npm run buildnpm run watchnpm run devTo verify your credentials work before using with Claude:
node test-auth.jsThis will attempt to authenticate and show detailed debug information.
Your API access level matches your Sling user permissions:
Admin tokens - Full access to all organization data
Employee tokens - Limited to that user's information only
The server now includes detailed debug logging. Check your MCP server logs (Claude Desktop Developer Console) for:
Response status code
Response headers
Response body
This will help identify where the token should be.
Quick fixes:
Verify credentials in .env are correct (no extra quotes/spaces)
Test login with curl:
curl -i -X POST https://api.getsling.com/account/login \
-H "Content-Type: application/json" \
-d '{"email":"your@email.com","password":"password"}'Look for authorization: header in the response
For detailed troubleshooting steps, see TROUBLESHOOTING.md
Verify your email and password are correct in .env
Check that you can log in to Sling web app with these credentials
Ensure you're using the correct server (api vs test-api)
Make sure you're not using OAuth provider credentials (Google/Facebook)
Check the error message for specific details
Verify your user has permission to access the requested resource
Ensure date formats are in ISO 8601 format (e.g., "2024-01-20T09:00:00Z")
Verify you have internet connectivity
Check if api.getsling.com is accessible
Try using SLING_SERVER=test-api for the staging environment
The server logs detailed authentication information to stderr:
All response headers from Sling API
Response body content
Token extraction attempts
View these logs in:
Claude Desktop: Help → Developer Tools → Console
Terminal: stderr output from the MCP server process
MIT
Contributions are welcome! Please feel free to submit a Pull Request.
For issues with:
This MCP server: Open an issue in this repository
Sling API: Refer to Sling API documentation
MCP Protocol: See MCP documentation
Create a sales record. Used for tracking sales data and labor analytics.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date of the sale (ISO 8601 format) | |
| amount | Yes | Sale amount | |
| location | No | Location where the sale occurred | |
| data | No | Additional sales data as JSON object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits such as side effects, idempotency, or permission requirements. For a creation tool, this is a significant gap.
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?
Two concise sentences with no superfluous information. Could be slightly more specific, but overall efficient and front-loaded.
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 and no description of return values or side effects. With moderate complexity (4 parameters, nested object), the description falls short in providing complete context for an agent.
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 the schema already documents all parameters adequately. The description adds no additional meaning beyond the schema, earning the 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?
Clearly states the action ('Create') and resource ('sales record'), and mentions the purpose for tracking sales data and labor analytics. Distinguishes from siblings since no other create_sales_record tool exists.
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 versus alternatives. Does not mention when not to use or provide context for choosing among sibling create tools like create_shift or create_user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new shift for a user. Shifts represent scheduled work periods.
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | User identifier who will work this shift | |
| startTime | Yes | Shift start time (ISO 8601 format) | |
| endTime | Yes | Shift end time (ISO 8601 format) | |
| position | No | Position/role for this shift | |
| location | No | Location where the shift takes place | |
| data | No | Additional shift data as JSON object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic creation action without mentioning permissions, side effects, or constraints like overlapping shifts, leaving the agent unaware of important traits.
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 short and front-loaded with the main action. Both sentences earn their place, but it could be slightly more informative without losing conciseness.
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 complexity (6 params, nested object, no output schema), the description lacks important context such as what the tool returns, permission requirements, and side effects. This is insufficient for a creation 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?
All six parameters are fully described in the input schema (100% coverage), so the description adds no additional meaning beyond what the schema provides. Baseline of 3 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 'Create a new shift for a user' and defines shifts as scheduled work periods. The verb and resource are specific, and the tool is distinguished from sibling tools like create_sales_record and create_user.
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, no prerequisites, and no exclusions. Even though the name is self-explanatory, explicit usage context is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new user in the organization.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | User email address | ||
| name | Yes | User full name | |
| role | No | User role (e.g., "employee", "manager", "admin") | |
| data | No | Additional user data as JSON object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. The minimal text does not mention side effects, idempotency, authorization requirements, or what happens on success/failure. This is insufficient for safe and correct invocation.
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 concise sentence with no wasted words. However, for a create operation with four parameters, additional context would be beneficial, but the brevity is not detrimental to the structure.
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 presence of a nested object parameter and no output schema, the description should explain the expected format of 'data' or the return value. It fails to provide enough context for a complete understanding of the tool's 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?
All parameters have descriptions in the schema (100% coverage), but the tool description adds no additional semantics beyond what the schema already provides. Baseline 3 applies; no extra value is contributed.
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 'Create a new user in the organization.' clearly specifies the verb (Create) and the resource (new user in organization), and it effectively distinguishes this tool from sibling tools like create_sales_record or create_shift.
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 (e.g., update_user), nor does it mention prerequisites or conditions for usage. The agent has no context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get calendar information for a specific user in an organization. Returns schedule and shift data for the specified date range.
| Name | Required | Description | Default |
|---|---|---|---|
| org | Yes | Organization identifier | |
| user | Yes | User identifier | |
| dates | Yes | Date parameter (e.g., "2024-01-01" or date range) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read operation ('Get') but does not disclose any potential side effects, permissions, rate limits, or return format details beyond 'schedule and shift data.'
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 is clear and to the point, with no redundant or extraneous information.
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 no output schema, the description could provide more detail on the return format or data structure. It mentions 'schedule and shift data' but lacks specifics, which is acceptable for a simple retrieval but not fully 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?
Schema coverage is 100% with descriptions for all three parameters. The description adds context aligning with the parameters (e.g., 'specific user' matches 'user'), but does not add new meaning beyond what the schema already provides.
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 retrieves calendar information (schedule and shift data) for a specific user and organization within a date range. The verb 'Get' and resource 'calendar information' are specific, and the tool is distinct from siblings like get_timesheets.
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 versus alternatives (e.g., get_timesheets for timesheet data). The description does not provide context for appropriate use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of groups in the organization. Groups are used to organize users.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only implies a read-only operation ('Get list') without mentioning permissions, rate limits, or other behaviors like pagination or ordering.
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 extremely concise with two short sentences, no redundant information, and the main action is front-loaded.
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?
The description is adequate for a simple list tool with no parameters, but it lacks information about return values or potential pagination. Given the absence of an output schema, some explanation of what is returned would improve completeness.
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 no parameters, so the description does not need to add parameter meaning. The schema coverage is 100%, and the baseline for 0 params is 4.
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 groups'. It also provides context that groups are used to organize users, distinguishing it from sibling tools like 'get_users'.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It only states the basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get organization information. Returns details about your organization.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description should disclose behavioral traits. It only states that the tool returns details, without explicitly stating it is a read-only operation. No mention of rate limits, authentication needs, or what constitutes 'details.'
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 concise sentences, each adding value: the first states the action, the second the outcome. No extraneous words or repetitions.
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 tool with no parameters and no output schema, the description is fairly complete. It clarifies the purpose and implies scope ('your organization'). However, it could mention that the result is the user's current organization, especially given the sibling tool for retrieval by ID.
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 description coverage is 100% (vacuously). According to the rubric, high coverage gives a baseline of 3. The description adds no parameter-specific information, which is acceptable given no parameters exist.
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 retrieves organization information and returns details about 'your organization.' This implies it gets the current organization, but it does not explicitly distinguish from the sibling 'get_organization_by_id,' which likely requires an ID. The verb-resource pairing is specific.
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 is provided on when to use this tool versus alternatives like 'get_organization_by_id.' The description does not specify that this tool retrieves the current organization without an ID, nor does it mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get organization information by specific organization ID.
| Name | Required | Description | Default |
|---|---|---|---|
| orgId | Yes | Organization identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description bears full burden. Only states 'get organization information' without disclosing return format, completeness, or any side effects. Lacks detail for a mutation-free but potentially complex data fetch.
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?
Single short sentence, no redundancy. Could be slightly more efficient but appropriate for a simple 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?
Minimally adequate for a single-parameter lookup. However, no output schema means description should hint at return fields or scope; it does not, leaving ambiguity with sibling tools.
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 coverage is 100%, fully describing 'orgId'. Description adds no extra meaning beyond schema, meeting baseline.
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?
Description clearly states the action (get) and resource (organization information) with specific qualifier (by specific organization ID). Distinguishes from sibling 'get_organization' which likely lists all organizations.
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 versus alternatives like 'get_organization'. Does not specify prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get reports data. Reports provide analytics and insights about schedules, labor costs, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| reportType | No | Type of report to retrieve (e.g., "labor", "schedule", "attendance") | |
| startDate | No | Start date for report (ISO 8601 format) | |
| endDate | No | End date for report (ISO 8601 format) | |
| params | No | Additional report parameters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, potential side effects, pagination, or error behavior. The description adds minimal behavioral context beyond the obvious.
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 very concise with two short sentences, no extraneous information. However, it could benefit from more structure or clarity on what the tool does specifically.
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 no output schema and no annotations, the description lacks completeness. It does not explain return format, error handling, or the purpose of the nested 'params' object, leaving gaps for the agent.
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 coverage is 100%, with each parameter having a clear description. The tool description does not add extra meaning beyond the schema, so a baseline score of 3 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 the tool retrieves reports data and gives examples (schedules, labor costs), providing a clear verb and resource. However, it does not distinguish from sibling tools like get_timesheets or get_calendar that may serve similar 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?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of available tags. Tags are used to categorize and organize shifts, users, etc.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It correctly implies a read-only operation but lacks details on pagination, sorting, or permissions.
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?
Two efficient sentences: first states action, second provides context. No unnecessary 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?
For a simple list retrieval with no parameters or output schema, description is sufficiently explanatory. Could mention if all tags are returned or filtered, but overall adequate.
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?
No parameters in schema; description adds no parameter info, which is appropriate. Baseline for zero-parameter tool is 4.
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?
Description clearly states 'Get list of available tags' with specific verb and resource. It explains tags' purpose but does not differentiate from sibling tools like get_calendar or get_groups.
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 versus alternatives (e.g., create_tag if it existed). No context for usage scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get timesheet data. Timesheets track actual hours worked.
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | No | Start date for timesheet query (ISO 8601 format) | |
| endDate | No | End date for timesheet query (ISO 8601 format) | |
| userId | No | Optional: Filter by specific user |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as idempotence, side effects, or authentication requirements. For a read operation, this minimal disclosure is insufficient to fully inform an agent.
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 very concise with only two sentences. It is front-loaded with the primary action. However, it could be more informative without becoming verbose.
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?
Without an output schema, the description does not mention return values or behavior beyond 'Get timesheet data.' For a simple retrieve tool, this is somewhat adequate but leaves gaps for complex usage.
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 already describes all three parameters (startDate, endDate, userId) with clear descriptions, achieving 100% coverage. The tool description adds no additional meaning beyond the 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 that the tool retrieves timesheet data and briefly explains what timesheets are. While it does not explicitly distinguish from sibling tools, the name and context are sufficient for identifying its purpose.
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 versus alternatives like get_reports or get_calendar. The description lacks context about prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of users in the organization. Returns user information based on your access level.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only mentions basic purpose and access level, but does not disclose behavioral traits like pagination, rate limits, or auth requirements. No annotations are present to supplement transparency.
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 very concise at two sentences, front-loading the verb and resource with no wasted 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?
For a simple, no-parameter tool, the description covers the basics. However, it lacks details about return format (e.g., fields included, sorting, pagination) which would aid completeness.
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, so the description need not add parameter details. A baseline of 4 is appropriate as there is nothing omitted.
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 list of users' and the resource 'users in the organization', and mentions access level filtering, distinguishing it from sibling tools like create_user and update_user.
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 is provided on when to use this tool versus alternatives such as get_groups or get_organization. The description lacks context for choosing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a custom API call to any Sling endpoint. Use this for endpoints not covered by specific tools.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | HTTP method to use | |
| path | Yes | API endpoint path (e.g., "/users", "/calendar/123/users/456") | |
| params | No | Query parameters for GET requests | |
| data | No | Request body data for POST/PUT requests |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral context. It does not disclose potential destructive actions from POST/PUT/DELETE methods, authentication requirements, or error handling, leaving significant gaps for an API call tool.
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 consists of two concise sentences that front-load the purpose and usage context. There is no unnecessary information.
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 generic API caller with four parameters, the description is adequate, but lacks guidance on endpoint construction, authentication context, or error responses. However, the simplicity of the tool and schema compensate somewhat.
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 schema already documents all four parameters with descriptions (100% coverage). The description adds no additional meaning beyond the schema, meeting the baseline without enhancing understanding.
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 making custom API calls to any Sling endpoint, and explicitly distinguishes it from sibling tools by noting it should be used 'for endpoints not covered by specific tools'.
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 clear guidance on when to use this tool (for endpoints not covered by specific tools), implying that specific tools should be preferred. However, it does not explicitly state when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch to a different organization context.
| Name | Required | Description | Default |
|---|---|---|---|
| orgId | Yes | Organization identifier to switch to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits such as permissions required, side effects (e.g., changing subsequent API calls), or reversibility. The brief description provides none of this, leaving the agent unaware of important implications.
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 extremely concise, consisting of a single clear sentence. It is front-loaded and contains no extraneous information, 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 potential impact (changing organization context), the description is incomplete. It does not explain the return value, side effects on subsequent requests, or any prerequisites. For a state-changing tool, more detail is necessary.
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 coverage is 100% with one parameter 'orgId' described as 'Organization identifier to switch to'. The description adds no additional meaning or constraints beyond what the schema already provides, so a baseline score of 3 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 uses a specific verb 'Switch' and resource 'organization context', making the core action clear. However, it does not differentiate from sibling tools like 'get_organization' or 'get_organization_by_id', which might cause confusion about what 'switching' entails versus simply retrieving.
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 is provided on when to use this tool versus alternatives, nor any conditions or prerequisites. The description lacks context about when switching is appropriate or what state it affects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update organization or user settings.
| Name | Required | Description | Default |
|---|---|---|---|
| settingType | Yes | Type of setting to update (e.g., "organization", "user", "notifications") | |
| data | Yes | Settings data to update as JSON object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It states 'Update' implying mutation, but fails to describe side effects, idempotency, security requirements, or error conditions. The description is insufficient for an agent to understand the tool's impact.
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 concise sentence with no redundancy. It efficiently communicates the core function. However, it could be slightly expanded to improve clarity without becoming overly verbose.
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 has two parameters (one nested object) and no output schema or annotations, the description is too minimal. It lacks details on the expected structure of the 'data' object, possible values for 'settingType', and what the response indicates. This leaves significant gaps for the agent.
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 100% coverage with descriptions for both parameters, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides (e.g., examples of settingType are in the schema, not the description). Therefore, no extra value is added.
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 'Update organization or user settings' clearly states the verb and resource, and the schema provides examples of settingType. However, it does not explicitly differentiate from sibling tools like update_user or update_timesheet, which could cause confusion about which tool to use for specific settings updates.
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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., admin permissions) or context in which this tool is appropriate, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update timesheet data for a user.
| Name | Required | Description | Default |
|---|---|---|---|
| timesheetId | Yes | Timesheet identifier | |
| data | Yes | Timesheet data to update as JSON object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It merely states 'Update', which implies mutation, but offers no details on permissions, idempotency, side effects, or constraints.
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 short sentence, which is concise, but it omits critical details. It is adequately sized for a simple update operation but lacks necessary 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?
With no output schema or annotations, the description fails to provide complete context. It does not explain what data can be updated, what the response contains, or any usage constraints.
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 coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema, but the schema itself sufficiently documents the two parameters.
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 the verb 'update' and resource 'timesheet data for a user', giving a basic idea of the tool's function. However, it lacks specificity and does not distinguish it from sibling tools like get_timesheets or update_settings.
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 is provided on when to use this tool compared to alternatives. There is no mention of prerequisites, contexts, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing user in the organization.
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | User identifier | |
| data | Yes | User data to update as JSON object |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavioral traits. It only states 'update' without explaining side effects, idempotency, partial vs full replacement, or any constraints on the data object. This is insufficient for an agent to understand the tool's behavior.
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 extraneous information. It is concise, though it could benefit from slightly more detail without being wordy. The length is appropriate for the simplicity of the 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 two parameters (one nested object) and no output schema, the description is incomplete. It does not specify what the tool returns, whether updates are partial or full, or how to structure the data object. More context is needed for safe and correct usage.
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 covers 100% of parameters with descriptions, providing basic meaning. The tool description adds no additional context beyond the schema, such as format expectations for the userId or the structure of the data object. Baseline 3 is appropriate given full 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 action (update) and the resource (user) with scope (in the organization). It effectively distinguishes from sibling tools like create_user and get_users.
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 is provided on when to use this tool versus alternatives, such as when to update vs create or when changes require certain permissions. The description is minimal and lacks context for appropriate use.
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.
v1.0.0create_sales_recordcreate_shiftcreate_userget_calendarget_groupsget_organizationget_organization_by_idget_reportsget_tagsget_timesheetsget_userssling_api_callswitch_organizationupdate_settingsupdate_timesheetupdate_userMost tools have distinct purposes (e.g., create_shift, get_timesheets, update_user), but two organization retrieval tools (get_organization, get_organization_by_id) overlap slightly, and the generic sling_api_call could be confused with specific tools. Overall, the set is well-disambiguated.
All tools follow a consistent verb_noun pattern in snake_case (e.g., create_shift, get_users, update_timesheet). The only exception is sling_api_call, which still uses a noun_noun structure but is clearly named. The pattern is uniform and predictable.
With 16 tools, the count is slightly above the ideal 3-15 range but still appropriate for the domain. Each tool covers a distinct function (users, shifts, timesheets, settings, etc.), and no tool feels redundant.
The tool set covers core CRUD operations for users, shifts, timesheets, organizations, and settings, plus reporting and a generic API call. Missing delete operations and shift updates are minor gaps, but the generic API call mitigates them. Coverage is good for common workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage projects, tasks, time tracking, and team collaboration through natural language.
Staff scheduling — manage staff, shifts, assignments, certifications, and requests via AI.
Enable interaction with Slack workspaces. Supports subscribing to Slack events through Resources.
Schedule and manage Google Calendar events directly from your workspace. Check availability, view…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/poncheck/mcp-sling'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
