@blario/mcp
Version:
Blar Model Context Protocol server
132 lines (127 loc) • 8.23 kB
JavaScript
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { getPullRequestIssueByIdSchema, getPullRequestIssueByIdHandler, } from './tools/get-pull-request-issue-by-id.js';
import { getPullRequestIssuesSchema, getPullRequestIssuesHandler, } from './tools/get-pull-request-issues.js';
import { searchAllConsiderationsSchema, handleSearchAllConsiderations, } from './tools/search-all-considerations.js';
import { getHierarchicalConsiderationsSchema, getHierarchicalConsiderationsHandler, } from './tools/get_hierarchical_considerations.js';
import { createConsiderationSchema, createConsiderationHandler, } from './tools/create_consideration.js';
import { resolveIssueSchema, resolveIssueHandler, } from './tools/mark_issue_as_solved.js';
const CONSIDERATION_EXPLANATION = `<consideration>
A consideration is a factual, specific piece of information extracted directly from developers' context.
It serves as actionable context for an agent tasked with analyzing the code for potential bugs, security flaws, or design issues.
Considerations are not assumptions or interpretations — they are explicit observations about the system's structure, behavior, or constraints.
</consideration>`;
const RELATIVE_PATH_SPECIFICATION = `<relative_file_path>
Relative file path within the repository to scope the consideration. Supports granular scoping:
Scoping levels:
- File level: "src/components/Button.tsx"
- Class level: "src/components/Button.tsx#ButtonComponent"
- Method/Function level: "src/utils/helpers.ts.validateInput"
- Nested scoping: "src/components/Form.tsx#FormComponent.handleSubmit"
- Recursive nesting: "src/lib/parser.ts#Parser.parseTokens.handleSpecialCase"
Syntax rules:
- Use # for classes/interfaces/types
- Use . for functions/methods
- Chain them for nested scopes (classes in functions, functions in classes)
- Works recursively to any depth of nesting
Examples:
- "api/auth.ts.loginUser" - function in file
- "models/User.ts#UserModel" - class in file
- "utils/transform.ts.processData.sanitizeInput" - nested functions
- "components/Table.tsx#TableRow.renderCell.formatValue" - method in class with nested function
- "services/api.ts#ApiClient.request.handleRetry.exponentialBackoff" - deeply nested functions
</relative_file_path>`;
export function createServer() {
const server = new McpServer({
name: 'blar',
version: '1.0.0',
});
// Register get-pull-request-issue-by-id tool
server.tool('get-pull-request-issue-by-id', `${CONSIDERATION_EXPLANATION}
<use_case>
Retrieve detailed information about a specific pull request issue by its unique identifier.
Only works for issues created by Blar.
</use_case>.
<parameters>
issue_id: ID of the pull request issue
</parameters>.
<important_notes>
This tool is critical to get the details of a specific pull request issue, including its related considerations.
</important_notes>`, getPullRequestIssueByIdSchema, async (args) => await getPullRequestIssueByIdHandler(args));
// Register get-pull-request-issues tool
server.tool('get-pull-request-issues', `<use_case>
Retrieve all issues from a specific pull request by PR number with optional filtering and pagination
</use_case>.
<parameters>
pr_number: Pull request number,
agent_type: Filter by agent type (optional),
severity: Filter by severity level (optional),
repository: Filter by repository name in format <org>/<repo_name> (optional),
issue_source: Filter by issue source (blar, human, or all) (optional, default: all),
limit: Items per page (optional, max 100), offset: Starting position for pagination (optional)
</parameters>.
<important_notes>
This tool fetches issues from a PR with pagination support.
Use limit and offset for pagination control.
Repository filter is useful when multiple open PRs exist with same number.
Issue source filter helps distinguish between Blar-generated and human-created issues.
</important_notes>`, getPullRequestIssuesSchema, async (args) => await getPullRequestIssuesHandler(args));
// Register search-all-considerations tool
server.tool('search-all-considerations', `${CONSIDERATION_EXPLANATION}
<use_case> Search through all considerations using query, repository, and tag filters.</use_case>.
<parameters>
query: Search query to filter considerations.
repo_name: Repository name to filter considerations by.
tag: Tag to filter considerations by type (context or design_pattern).
</parameters>.
<important_notes>
This tool allows searching across all considerations with optional text, repository, and tag filtering.
</important_notes>`, searchAllConsiderationsSchema, async (args) => await handleSearchAllConsiderations(args));
// Register get-hierarchical-considerations tool
server.tool('get-hierarchical-considerations', `${CONSIDERATION_EXPLANATION}
<use_case>
Retrieve hierarchical considerations for a specific file path, including considerations linked to the file and all parent directories up to the repository root.
</use_case>
<parameters>
repo_name: Repository name to filter considerations by
relative_file_path: ${RELATIVE_PATH_SPECIFICATION}
</parameters>
<important_notes>
This tool returns considerations from the specific file path and all containing parent directories, providing a complete hierarchical view of applicable considerations.
Supports granular scoping - you can target specific classes, functions, or nested elements within files.
</important_notes>`, getHierarchicalConsiderationsSchema, async (args) => await getHierarchicalConsiderationsHandler(args));
// Register create-consideration tool
server.tool('create-consideration', `${CONSIDERATION_EXPLANATION}
<use_case>
Create a new consideration in a specific repository with title, description, optional code snippet and required tags.
</use_case>
<parameters>
repo_name: Repository name where the consideration should be created
consideration_title: Title of the consideration
consideration_description: Detailed description of the consideration
consideration_code_snippet: Optional code snippet related to the consideration
consideration_tags: Required array of tags for the consideration. Use ["context"] for descriptive background info, ["design_pattern"] for enforceable rules/patterns, or ["context", "design_pattern"] for both
relative_file_path: ${RELATIVE_PATH_SPECIFICATION}
</parameters>
<important_notes>
This tool creates a new consideration from MCP input. Tags definitions:
- "context": Descriptive background information about the project, design conventions, library usage, framework behavior, or architectural information
- "design_pattern": Information that can be implemented as enforceable coding rules, design patterns, project standards, or best practices
- For considerations that serve both purposes, send both tags: ["context", "design_pattern"]
Scoping behavior:
- Global (no relative_file_path): Applies to entire repository
- File scoped: Applies to specific file and its contents
- Granular scoped: Applies to specific classes, functions, or nested elements within files
- Hierarchical propagation: Scoped considerations apply to their scope and all nested elements
</important_notes>`, createConsiderationSchema, async (args) => await createConsiderationHandler(args));
// Register resolve-issue tool
server.tool('resolve-issue', `<use_case>
Mark a pull request issue as resolved both internally and in the Git platform (e.g., GitHub).
</use_case>
<parameters>
issue_id: ID of the pull request issue to resolve
</parameters>
<important_notes>
This tool will attempt to resolve the issue. If the issue is already resolved or cannot be resolved, the response message will indicate the outcome.
</important_notes>`, resolveIssueSchema, async (args) => await resolveIssueHandler(args));
return server;
}