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., "@WBSO MCP Server analyze my latest commit for WBSO relevance"
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.
Generic MCP (Model Context Protocol) server for WBSO R&D documentation and time tracking. Enables AI assistants like Claude Code to automatically detect WBSO-relevant work and log entries.
WBSO Detection - Analyze commits, code, and work descriptions for WBSO eligibility
Work Classification - Classify work into technical challenge areas
Automatic Logging - Log research and development entries to documentation
Multi-year Support - Track hours across multiple WBSO project years
Configurable - Define your own technical challenges and keywords
Related MCP server: YesDev MCP Server
git clone https://github.com/rubenmaas/wbso-mcp-server.git
cd wbso-mcp-server
npm installThe server loads project configuration from wbso.config.json in your WBSO documentation directory.
Copy the example config:
cp wbso.config.example.json /path/to/your/wbso-docs/wbso.config.jsonEdit the config with your project details:
{
"project": {
"name": "Your Project Name",
"projectNumber": "2025-1",
"company": "Your Company B.V."
},
"years": {
"2025": {
"totalHours": 1000,
"type": "New project"
}
},
"technicalChallenges": [
{
"id": "challenge-1",
"name": "Challenge Name",
"keywords": ["keyword1", "keyword2"],
"researchLogs": ["research-log"],
"devLogs": ["dev-log"]
}
]
}Add to your Claude Code config (~/.claude/claude_desktop_config.json):
{
"mcpServers": {
"wbso": {
"command": "node",
"args": ["/path/to/wbso-mcp-server/index.js"],
"env": {
"WBSO_DIR": "/path/to/your/wbso-docs"
}
}
}
}Tool | Description |
| Analyze if code/commits are WBSO-relevant |
| Classify work into technical challenge areas |
| Check if a git commit qualifies as WBSO work |
| Get full project criteria and challenges |
Tool | Description |
| Log research entries to documentation |
| Log development entries to documentation |
| Log time entries for the current week |
| Get current WBSO hours status |
{
"project": {
"name": "Project Name",
"projectNumber": "2025-1",
"company": "Company B.V."
}
}{
"years": {
"2025": {
"applicationNumber": "SO25XXXXXX",
"period": "January - December 2025",
"totalHours": 1000,
"type": "New project"
}
}
}{
"technicalChallenges": [
{
"id": "unique-id",
"name": "Challenge Name",
"description": "Description of technical uncertainty",
"keywords": ["keyword1", "keyword2"],
"filePatterns": ["pattern1", "pattern2"],
"researchLogs": ["log-name"],
"devLogs": ["log-name"]
}
]
}{
"relevantPaths": ["service", "repository", "controller"],
"excludePatterns": ["node_modules", "vendor", "\\.lock$"]
}Variable | Description | Default |
| Path to WBSO documentation directory | Current working directory |
MIT
Analyze whether code, commits, or work description is relevant to the WBSO project.
| Name | Required | Description | Default |
|---|---|---|---|
| diff | No | Git diff or code changes | |
| content | Yes | The content to analyze | |
| files_changed | No | List of file paths changed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It does not mention whether the tool has side effects, what the output format is, or any prerequisites. This is especially important given sibling tools that log research or development, potentially implying write operations.
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 wasted words. It efficiently conveys the core purpose, though it is brief and could benefit from additional context.
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 annotations, no output schema, and a minimal description, the tool is under-specified. It does not explain what 'relevant' means, what the expected output is, or how to structure the input for different use cases. This is inadequate for a tool with multiple input parameters.
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 covers all three parameters (diff, content, files_changed) with 100% coverage, setting the baseline at 3. The description adds context about WBSO relevance but does not clarify which parameter corresponds to 'code', 'commits', or 'work description' beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool analyzes code, commits, or work description for relevance to the WBSO project, using a specific verb and resource. It is understandable but does not explicitly differentiate from sibling tools like check_commit_wbso, which likely serves a similar 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 is provided on when to use this tool versus alternatives such as classify_work or check_commit_wbso. The description only states what the tool does, leaving the agent to infer appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a git commit should be logged as WBSO work
| Name | Required | Description | Default |
|---|---|---|---|
| commit_hash | No | Git commit hash (uses HEAD if not provided) | |
| repository_path | No | Path to the git repository |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the purpose. It does not mention side effects (though 'check' implies read-only), return format, or any dependencies like repository access. This leaves significant behavioral ambiguity for 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 a single sentence with no fluff, front-loading the core purpose immediately. It is extremely concise and well-structured for a one-line definition.
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 tool is simple (2 params, no output schema, no annotations), but the description is too minimal. It does not explain what the tool returns (e.g., boolean, explanation) or how it determines WBSO eligibility, leaving a key gap in understanding how to interpret results.
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%, meaning both parameters (commit_hash and repository_path) are already well-described. The tool description adds nothing about parameters, but the baseline for full schema coverage is 3, so this score 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's function: checking if a git commit should be logged as WBSO work. It uses a specific verb ('check') and resource ('git commit'), making the purpose straightforward. However, it does not explicitly differentiate from sibling tools like analyze_wbso_relevance or classify_work, so it falls short of a 5.
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 like analyze_wbso_relevance or get_wbso_criteria. There are no context cues, exclusions, or alternative mentions, leaving the usage context entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify work into the appropriate WBSO technical challenge area
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Primary file being worked on | |
| description | Yes | Description of the work done |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does not indicate whether the tool is read-only, whether it persists data, what output it returns, or any side effects. This is a significant transparency gap for a classification 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 a single, direct sentence with no fluff. It is front-loaded with the verb and delivers the core message efficiently. While terse, it earns its place and is appropriately sized for a simple classification 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 lack of annotations and output schema, the description is incomplete. It does not explain what the classification result looks like, whether the tool modifies state, or how it relates to sibling tools like log_time or analyze_wbso_relevance. Agents would need to guess or experiment to use it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both 'filename' and 'description', so the schema already documents the parameters. The description adds no extra meaning about parameter usage, thus 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 tool's function: classifying work into a WBSO technical challenge area. It uses a specific verb ('Classify') and identifies the resource ('work') and outcome ('WBSO technical challenge area'). However, it does not explicitly differentiate from sibling tools like analyze_wbso_relevance or get_wbso_criteria, which overlap in domain.
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 offers no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It is a bare statement of function without contextual instructions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full WBSO project criteria and technical challenges
| 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. It implies a read-only operation ('Get') but does not disclose any behavioral details like data scope, pagination, or authentication requirements. It offers minimal transparency beyond the basic action.
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 that clearly states the tool's purpose without unnecessary words or repetition. It is appropriately sized 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?
For a simple getter with no parameters and no output schema, the description is adequate but minimal. It does not describe the return format or how this tool fits with siblings, leaving some ambiguity about the 'full' criteria and technical challenges.
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 of 4 applies. There are no parameter semantics to explain, and the description does not need to compensate for missing schema 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 uses a specific verb 'Get' and a clear resource 'full WBSO project criteria and technical challenges'. It is distinct from siblings like 'get_wbso_status' which focuses on status, though it does not explicitly name alternatives.
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 other WBSO-related siblings such as analyze_wbso_relevance or check_commit_wbso. The description only states what it does, not the context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current WBSO documentation status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It merely says 'Get current WBSO documentation status', implying a read-only operation, but does not explain what the status contains, whether any side effects occur, or how the result is formatted. This is a significant gap for an agent relying on the description.
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 direct and free of extraneous information. It is appropriately concise for a tool with no parameters and a straightforward purpose.
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 too sparse given the absence of an output schema and annotations. It does not specify what 'WBSO documentation status' entails, how the status is returned (e.g., a string, a structured object), or any relevant context. An agent cannot fully anticipate the tool's response, making the description incomplete even for a simple getter.
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 baseline is 4. The description adds the 'current' qualifier, which hints that the status reflects real-time state, but there is nothing more to explain since there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get current WBSO documentation status' uses a clear verb ('Get') and a specific resource ('current WBSO documentation status'), distinguishing it from sibling tools that analyze, classify, check, or log activities. However, it does not explicitly contrast with 'get_wbso_criteria', which could be confused with a status lookup.
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 does not mention that this should be used for retrieving the status of WBSO documentation, nor does it exclude the criteria-getting tool. The agent is left to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log a development entry to WBSO documentation
| Name | Required | Description | Default |
|---|---|---|---|
| hours | Yes | Hours spent | |
| branch | No | Branch name | |
| commits | No | Commit hashes | |
| results | Yes | What worked or didnt work | |
| approach | No | How you implemented this | |
| jira_ref | No | Jira issue reference | |
| log_name | Yes | Name of the development log | |
| learnings | No | Technical insights gained | |
| repository | No | Repository name | |
| technical_challenge | Yes | The technical problem being solved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states that a development entry is logged, implying a mutating operation, but gives no details about side effects, permissions, idempotency, or whether it appends to a file. The schema lists parameters, but the description does not clarify behavior such as whether previous entries are overwritten or if authorization is required.
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 that immediately conveys the core purpose. It is front-loaded and has no redundant wording. However, the acronym 'WBSO' is unexplained, which slightly reduces clarity, but the overall structure is efficient and appropriate for a tool description.
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 10 parameters, 4 required, no output schema, and no annotations, the description is too sparse. It does not explain return values, what constitutes a valid entry, or how this tool relates to siblings like log_time or log_research. The complexity of the input schema and the absence of an output schema call for more detail about the tool's workflow and outcomes.
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%, meaning every parameter (hours, branch, commits, etc.) is already described in the schema. The description 'Log a development entry' adds minimal semantic context beyond the schema, merely indicating that the entry is development-related. Therefore, a baseline score of 3 is appropriate, as the schema handles the parameter documentation burden.
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 'Log a development entry to WBSO documentation' clearly identifies the action (log), the resource (development entry, WBSO documentation), and implies a specific domain. It distinguishes itself from sibling tools like log_research and log_time by focusing on 'development' rather than research or time tracking. However, it does not explain what WBSO documentation is, which could confuse agents unfamiliar with the term.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention when not to use it, nor does it reference sibling tools like log_research or log_time for differentiation. Usage context is only implied by the term 'development entry', which is insufficient for an agent to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log a research entry to WBSO documentation
| Name | Required | Description | Default |
|---|---|---|---|
| hours | Yes | Hours spent | |
| approach | No | How you investigated this | |
| findings | Yes | What you discovered | |
| jira_ref | No | Jira issue reference | |
| log_name | Yes | Name of the research log | |
| conclusion | No | Decisions made or next steps | |
| technical_uncertainty | Yes | The technical question being investigated |
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 only states the action 'log' without disclosing side effects (e.g., writes to WBSO documentation), permission requirements, or any return/error behavior. This is minimal disclosure for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loading the key action and target. It is appropriately concise for the simple operation it describes.
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 tool is a straightforward logging operation, and the schema covers parameter details. However, the description lacks context about what WBSO documentation is, what constitutes a research entry, and how this relates to sibling tools like log_development. It is adequate but minimal.
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 describes all 7 parameters with 100% coverage. The description itself adds no param-specific meaning beyond what the schema already provides. The baseline of 3 applies since the schema handles the heavy lifting.
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 'log' and the resource 'research entry to WBSO documentation'. It implicitly distinguishes from sibling tools like log_development by specifying 'research', but does not explicitly call out the differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as log_development or log_time. It does not mention any prerequisites, exclusions, or context for when logging a research entry is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log time spent on WBSO R&D work
| Name | Required | Description | Default |
|---|---|---|---|
| hours | Yes | Hours to log | |
| jira_ref | No | Jira issue reference | |
| description | Yes | Brief description of work done | |
| activity_type | Yes | Type of activity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It only states the action and target, but fails to mention any side effects, required permissions, reversibility, or output expectations. For a logging operation, this is minimal but acceptable for a simple action; however, it lacks depth.
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, front-loaded sentence with no filler or redundancy. It efficiently communicates the core action, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage and a simple operation, the description is mostly sufficient. However, the existence of sibling tools with overlapping functionality creates a contextual gap: the description doesn't clarify how this generic logger relates to log_research/log_development, which is a missing piece for complete guidance.
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 parameters are already well-documented in the input schema. The description adds no additional meaning beyond the schema, but the baseline of 3 is appropriate when the schema fully documents 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 clearly states the verb (log) and resource (time spent on WBSO R&D work), making the primary purpose unambiguous. However, it does not differentiate from sibling tools like log_research or log_development, which could lead to selection ambiguity.
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 generic tool versus the more specific log_research and log_development siblings. The description simply states the action without contextualizing its place among alternatives, leaving the agent to infer appropriate usage.
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.0analyze_wbso_relevancecheck_commit_wbsoclassify_workget_wbso_criteriaget_wbso_statuslog_developmentlog_researchlog_timeThe tools analyze_wbso_relevance, classify_work, and check_commit_wbso all serve to determine whether work qualifies as WBSO and how to categorize it, creating significant overlap. While descriptions differ slightly (relevance check, classification, commit-specific check), an agent could easily misselect among them.
All tool names follow a snake_case verb_noun pattern (analyze_, classify_, check_, get_, log_), which is consistent. Minor inconsistency exists in whether 'wbso' appears in the noun part (analyze_wbso_relevance, get_wbso_criteria vs. classify_work, log_time), but overall the pattern is clear and predictable.
With 8 tools, the server is well-scoped for WBSO management, covering analysis, classification, logging, and status retrieval without unnecessary redundancy. The number feels appropriate for the domain and each tool appears to contribute to the workflow.
The tool set covers the core WBSO workflow: checking relevance, classifying work, logging research/development/time, and viewing criteria/status. Minor gaps exist—such as no update or delete operations for logged entries—but for the apparent purpose of documentation and tracking, the surface is reasonably complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Privacy-first work tracking with summaries, reports, coaching, and AI-ready long-term memory.
Track billable time from your AI chat: timers, entries, reports, CSV export. All data stays local.
Time tracking and invoicing for AI agents and their humans: track, log and bill work by agent.
Manage projects, tasks, time tracking, and team collaboration through natural language.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rubenmaas/wbso-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
