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., "@bamboohr-mcp show me time-off requests for next week"
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.
A read-only Model Context Protocol server for BambooHR.
This is a fork of evrimalacan/mcp-bamboohr (MIT). See NOTICE for attribution and the full list of changes.
BambooHR is sensitive HR data, so this fork hardens the upstream server for exposing it to an AI assistant safely. Design priorities: read-only by construction, least privilege, and the host process holds no credential. The upstream server is a clean, well-tested base; this fork hardens it for that posture:
Read-only by construction. The HTTP client exposes only get/getBuffer
— post/put/delete were removed, so no write tool can be added by
accident. Every registered MCP tool is a GET.
Proxy-ready, credential-free. Set BAMBOO_BASE_URL to a loopback
token-proxy and the server sends no Authorization header — the proxy
injects a fresh OAuth Bearer per request. The BambooHR credential never
lives in this process.
Injectable config. The credential is resolved in config.ts and passed
into the client, not hardwired into a boot-time singleton — so a future
multi-tenant/remote host can construct a per-request client without
touching the tool layer.
Related MCP server: Slack MCP Server
Two shapes (see .env.example):
Proxied (recommended for shared / sensitive use):
{
"mcpServers": {
"bamboohr": {
"command": "node",
"args": ["build/index.js"],
"type": "stdio",
"env": {
// A loopback proxy injects Authorization; no token here.
"BAMBOO_BASE_URL": "http://127.0.0.1:7339"
}
}
}
}Direct (a local/desktop setup with your own API key):
{
"mcpServers": {
"bamboohr": {
"command": "node",
"args": ["build/index.js"],
"type": "stdio",
"env": {
"BAMBOO_API_TOKEN": "your_api_token",
"BAMBOO_COMPANY_DOMAIN": "your_company_subdomain"
}
}
}
}Tool | Purpose |
| Employee record with selectable fields |
| Employee photo by size |
| Company-wide directory |
| Performance goals for an employee |
| Projected time-off balances |
| Time-off requests (filterable) |
| Upcoming time off + holidays |
| Browse company files/categories (metadata) |
| Download a company document by id |
| Discover available BambooHR data fields |
Egress note. Some tools (directory, file download) can return large volumes of PII. For shared / sensitive deployments, enforce row/size caps and field scoping at the proxy in front of this server, rather than trusting the tool layer.
Set BAMBOO_ENABLED_TOOLS to a comma- or space-separated allowlist to control
which tools register. Unset = all tools. This lets you switch tools on/off by
config alone — no code change — which is the clean way to keep tools whose
BambooHR OAuth scope you didn't grant switched off, so the agent is never
offered a tool that would 403. Unknown names are warned and ignored (never
fail the server). Example (the read-only set covered by directory + employee
name/job/photo + time-off scopes):
BAMBOO_ENABLED_TOOLS=get-employee,get-employee-photo,get-employee-directory,estimate-time-off-balance,get-time-off-requests,get-whos-out,get-meta-fieldsnpm install
npm run build
npm test
npm run dev # watch modeTypeScript (strict), ESM, Node ≥22. Tests run under Jest.
Read-only data access only. There are deliberately no write tools. Adding any write capability is an explicit decision that changes the security posture — not a casual PR.
Calculate future time off balances for an employee. Returns array of time off types with current balance, units (days/hours), policyType (accruing/discretionary/manual), and usedYearToDate amounts.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Future date to estimate balance for (YYYY-MM-DD format) | |
| employeeId | Yes | The employee ID to estimate time off balance for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It adds useful context about the return structure (array of time off types with specific fields) and indicates the operation is a calculation. However, it does not clarify behavior for edge cases (e.g., omitted date, past dates) or explicitly state that the operation is read-only and has no side effects.
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, front-loaded with the main action, and every sentence provides substantive information. It avoids redundancy and is appropriately sized 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?
For a low-complexity tool with good schema coverage and no output schema, the description is fairly complete. It explains the main purpose and return format. However, it omits behavior when the optional 'date' parameter is not provided, which is a minor gap.
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% description coverage for both parameters (employeeId and date), including formats and purpose. The tool description adds no additional parameter semantics beyond what the schema already states, so the baseline of 3 applies.
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 indicates the tool calculates future time off balances for an employee, with the verb 'Calculate' and resource 'future time off balances'. It also lists the specific return fields (current balance, units, policyType, usedYearToDate), distinguishing it from sibling tools like get-time-off-requests or get-whos-out.
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. It does not mention prerequisites, typical scenarios, or explicitly contrast with sibling tools like get-time-off-requests. The use case is implied by the name but not stated as guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a specific company document by ID. Returns file data with base64-encoded content for binary files (PDFs, images, etc.) along with file size and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| fileId | Yes | The ID of the company file to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It supplements the schema by specifying that binary files are returned as base64-encoded content, and that the response includes file size and metadata. This goes beyond the parameter schema, though it does not detail error cases or authentication requirements.
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, front-loaded with the main action, and every word adds value. There is no fluff or repetition of schema details.
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 tool with one parameter and no output schema, the description provides sufficient context: the download action, handling of binary files (base64), and additional metadata. The only minor gap is the lack of clarification for non-binary files, but overall this is largely 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 description coverage is 100% for the sole parameter (fileId), so the schema already explains its purpose. The description adds no new parameter semantics beyond the schema, which is acceptable at the baseline of 3 for high 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 uses a specific verb ('Download') and resource ('specific company document') with an explicit mechanism ('by ID'). This clearly distinguishes it from sibling tools like list-company-files (which lists files) and employee-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 implies usage: you need a file ID and want the document content. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites like obtaining the ID via list-company-files. There are no exclusions but no explicit 'when not to use' guidance either.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get employee data with customizable field selection. Returns employee object with fields like displayName, firstName, lastName, jobTitle, department, division, location, supervisor, photoUrl, and many more based on the 'fields' parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Employee ID (use "0" for current user associated with API key) | 0 |
| fields | No | Comma-separated list of fields to retrieve. Available fields include: displayName, firstName, lastName, preferredName, email, workEmail, jobTitle, department, division, location, workPhone, supervisor, linkedIn, pronouns, photoUploaded, photoUrl, canUploadPhoto, and many more. | firstName,lastName,email,jobTitle |
| onlyCurrent | No | Set to false to return future dated values from history table fields |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states that it 'Returns employee object with fields' and mentions customization, which partially describes behavior. However, it does not disclose error handling, read-only nature, or other operational details. The description adds some value but not rich 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 two sentences long, front-loaded with the core action, and avoids unnecessary details. It efficiently conveys the purpose and key behavior without 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 (3 optional parameters, no output schema), the description adequately covers the core functionality. It lists common fields and explains the field selection mechanism. While it doesn't address sibling tool distinctions, the description is sufficient for a straightforward employee data retrieval 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 the baseline is 3. The description lists example fields and references the 'fields' parameter, but does not add significant meaning beyond the schema's parameter descriptions. It reinforces the parameter behavior without adding new 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 verb 'Get' and the resource 'employee', and specifies the customizable field selection capability. It distinguishes itself from sibling tools like get-employee-photo and get-employee-directory by focusing on general employee data with flexible field retrieval.
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 context that this is the tool for retrieving employee data with selectable fields. It does not explicitly mention alternatives or exclusions, but the broad scope of the tool is self-evident. Sibling tools are specialized, making usage context reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the company-wide employee directory. Returns array of employee objects with comprehensive information including displayName, jobTitle, department, division, location, supervisor, workEmail, photoUrl, and more.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output format (array), the scope (company-wide), and the included fields, which is meaningful behavioral detail. It does not mention auth or rate limits, but for a simple read-only directory getter this is reasonable.
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, well-structured sentence that leads with the primary action and scope, then enumerates the return fields. 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?
Given the tool's simplicity (no parameters, no output schema), the description is almost complete. It names the return type, scope, and representative fields, though 'and more' is slightly vague. Still, it gives an agent enough context to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed; the schema already covers everything.
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 uses specific verb 'Get' and resource 'company-wide employee directory', clearly distinguishing it from sibling tools like get-employee (singular). It also specifies the return type (array of employee objects) and key fields, making the tool's function unmistakable.
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 phrase 'company-wide employee directory' conveys clear context: use when you need the full directory rather than an individual employee. However, it does not explicitly name alternatives or exclusion scenarios, so it misses the highest bar for when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get performance goals and objectives for an employee. Returns goal objects with title, description, percentComplete, status, dueDate, milestones (for milestone-based goals), and progress tracking information.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Filter goals by status | all |
| employeeId | Yes | The employee ID to get goals for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose the return fields (title, description, percentComplete, status, dueDate, milestones) and notes that milestones apply only to milestone-based goals. However, it does not mention error conditions, authentication requirements, or whether the operation is strictly read-only (though 'Get' and 'Returns' imply this). Provide more context on edge cases would increase 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 two sentences: the first states the tool's core purpose, the second lists the key return fields. It is concise, front-loaded, and every sentence adds value without 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 (2 params, no output schema, no annotations), the description covers the essential return shape and purpose. It could optionally note the filter parameter's effect, but the schema already enumerates 'open', 'closed', and 'all' with a default. The description is complete enough for an agent to invoke it correctly for a straightforward goal-retrieval task.
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 clear descriptions for both 'employeeId' and 'filter' (including enum values and default). The description adds no additional parameter semantics—it only mentions return fields. Per the rubric, baseline is 3 when schema covers parameters, and the description does not need to repeat that information.
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 and resource: 'Get performance goals and objectives for an employee.' This distinguishes it from sibling tools like get-employee-photo or list-company-files, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need an employee's goals, but it does not explicitly mention alternatives or exclusions. For example, it does not say 'use get-employee-directory instead for contact info.' The purpose itself gives enough context for a straightforward getter, but there is no explicit when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an employee photo by size
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Photo size | medium |
| employeeId | Yes | The employee ID to get the photo for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden, but it merely restates the tool's purpose. It fails to disclose response format (e.g., binary image vs URL), behavior for missing photos, or any permissions needed, making it nearly information-free beyond the name.
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, readable sentence with no redundancy. It is appropriately concise for a simple tool, though the brevity contributes to under-specification in other dimensions.
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 or annotations, the description must explain return behavior and edge cases, but it does not. It is unclear whether the tool returns raw image data, a download URL, or something else, leaving the agent under-informed for a complete invocation.
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 provides 100% coverage with clear descriptions for both employeeId and size. The description adds no extra semantic value beyond schema, so baseline 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 fetches an employee photo, with 'get' as the verb and 'employee photo' as the resource. It is easily distinguishable from sibling tools like get-employee or get-employee-directory, though it does not explicitly mention returning image 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?
No guidance is provided on when to use this tool versus alternatives. The description simply says 'by size' without explaining any prerequisites, exclusions, or comparison to other employee-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover all available BambooHR data fields. Returns array of field definitions with id, type (text/email/list/etc.), name, and optional alias. Essential for understanding what employee data fields can be requested.
| 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 carries the full behavioral burden. It discloses the return format (array with id, type, name, optional alias) and implies a read-only 'discover' operation. However, it does not explicitly state authentication needs, rate limits, or side effects, leaving some behavioral transparency gaps. The description adds value beyond the purpose but does not fully cover potential behavioral concerns.
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 only two sentences and front-loads the core purpose. It wastes no words while conveying the tool's scope and output. Every phrase contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema, no annotations), the description explains the return shape and its purpose. It is complete for a metadata-discovery tool. A minor gap is that it does not specify whether this includes custom fields or requires any special permissions, but the tool is still likely usable without that detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema contains nothing to explain. The baseline for 0 parameters is 4. The description adds useful context by detailing the structure of the returned field definitions, which is more than the empty schema 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's function: 'Discover all available BambooHR data fields.' It uses a specific verb ('discover') and resource ('data fields'), and it distinguishes itself from sibling tools that focus on specific employee records (e.g., get-employee, get-employee-photo) by returning field metadata rather than actual employee 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 provides clear context: 'Essential for understanding what employee data fields can be requested.' This implies using the tool before querying employee data. However, it does not explicitly mention when not to use it or name alternative tools, falling short of the explicit when/when-not guidance required for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve and filter time off requests. Returns request objects with id, employeeId, status, start/end dates, request type, amount, available actions (approve/deny/etc.), and employee/manager notes. Supports extensive filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Specific request ID to limit the response to | |
| end | No | End date filter (YYYY-MM-DD format) | |
| type | No | Filter by time off type ID | |
| start | No | Start date filter (YYYY-MM-DD format) | |
| action | No | Limit to requests that the user has a particular level of access to | view |
| status | No | Filter by request status | |
| employeeId | No | Specific employee ID to filter requests for |
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 discloses the operation is a read/filter (via 'Retrieve and filter'), and it adds useful context about returned fields including 'available actions (approve/deny/etc.)'. However, it does not explicitly state read-only behavior, permissions, pagination, or response format. It is not misleading but leaves some transparency gaps.
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, front-loaded with purpose, and every sentence contributes. It avoids fluff and conveys the key points (retrieve/filter, return fields, filtering capability) efficiently.
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, the description takes responsibility for explaining return values, and it does list key fields (id, employeeId, status, dates, type, amount, actions, notes). However, it omits details like pagination, default limits, sorting, or how multiple filtering parameters combine. It is adequate for a simple list tool but not fully complete for a 7-parameter endpoint.
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 baseline is 3. The description mentions 'extensive filtering' but does not add meaning beyond what the schema already documents for each parameter. It reinforces the filtering nature but does not introduce new semantics or parameter relationship 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 tool's function: 'Retrieve and filter time off requests.' It uses a specific verb ('retrieve', 'filter') and resource ('time off requests'), and the listed sibling tools (e.g., get-employee, estimate-time-off-balance) are distinct enough to avoid confusion. It fully distinguishes itself from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving and filtering time off request records, which is a clear context. However, it does not explicitly mention when not to use this tool or name specific alternatives (e.g., get-whos-out for who is out, estimate-time-off-balance for balances). It lacks exclusion guidance but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View upcoming time off and holidays for a date range. Returns array of mixed events: timeOff events (id, type, employeeId, name, start, end) and holiday events (id, type, name, start, end) with summary counts.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | End date (YYYY-MM-DD format) - defaults to 14 days from start date | |
| start | No | Start date (YYYY-MM-DD format) - defaults to current date |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. 'View' implies read-only, and the description discloses the return structure in detail (mixed events, fields, summary counts). However, it does not mention any potential side effects, auth requirements, or limitations. The return format is a useful behavioral disclosure, but authentication and rate limits are absent.
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, front-loaded with purpose, followed by a clear understanding of return format. 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?
The description explains the return types and fields, but 'summary counts' is vague and no structural details are provided for the counts. Without an output schema or annotations, more clarity on the response object would be needed for full completeness. The core purpose is clear, but edge cases and limits are unaddressed.
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 both start and end parameters clearly documented including defaults. The description adds no param-specific details beyond what the schema already provides, so the baseline of 3 applies.
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 'View' and resource 'upcoming time off and holidays for a date range', which is specific. It doesn't explicitly differentiate from the sibling tool 'get-time-off-requests', but the inclusion of holidays and mixed event types implies a broader scope.
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, no exclusions or prerequisites. The tool simply states its function without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse available company files and categories. Returns organized structure with file categories, each containing files with id, name, originalFileName, size, dateCreated, and category information.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of transparency. It discloses the return structure (categories and file fields), making it clear this is a metadata listing, not a download. However, it omits potential details like pagination or authorization, but these are not critical for a simple list 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 is only two sentences, with the main purpose front-loaded. Every sentence adds value: the first states the action, the second details the return structure. No filler 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, sibling differentiation), the description fully covers the essentials: it states what is returned and the data fields. It is sufficiently complete for an agent to know when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so the description need not explain any. The baseline for 0-parameter tools is 4, and the description adds no confusing parameter info, making it 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's function: browsing available company files and categories. It uses a specific verb ('browse') and resource ('company files'), and distinguishes itself from the sibling tool 'get-company-file' by emphasizing the listing/overview nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for browsing/listing files but does not explicitly state when to use it versus alternatives like 'get-company-file'. There is no mention of when not to use it or any exclusion criteria.
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.
v0.1.3estimate-time-off-balanceget-company-fileget-employeeget-employee-directoryget-employee-goalsget-employee-photoget-meta-fieldsget-time-off-requestsget-whos-outlist-company-filesMost tools target distinct resources (employee, photo, directory, goals, files, time-off balance, time-off requests, who's out, meta fields). However, get-time-off-requests and get-whos-out both relate to time off and could be confused, though their purposes differ (requests vs. calendar view).
All tools follow a consistent verb-noun pattern with kebab-case (e.g., get-employee, list-company-files, get-whos-out). The distinction between 'get' for singular resources and 'list' for collections is uniformly applied.
10 tools is well-scoped for a read-only HR data server, covering employees, directories, goals, files, time-off, and metadata without being overwhelming. Each tool serves a clear purpose.
The tool set covers many read operations (employee details, directory, goals, files, time-off), but lacks write operations. Since get-time-off-requests mentions approve/deny actions but no tool executes them, there is a notable gap for workflows that require action, not just data retrieval.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
The Ramp MCP server enables users to securely connect Ramp with AI assistants like ChatGPT and Claude to query financial data and take actions using natural language. It transforms Ramp's developer API into a SQL interface that LLMs can query, allowing admins to analyze spend trends, identify cost savings, and run complex SQL analyses on comprehensive datasets (transactions, purchase orders, vendors, users), while all users can manage cards, view transactions, request reimbursements, and get expense policy answers.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lovelight-code/bamboohr-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
