Skip to main content
Glama
sapientpants

DeepSource MCP Server

by sapientpants

projects

List all available DeepSource projects to access code quality metrics and analysis results for monitoring software health.

Instructions

List all available DeepSource projects. Returns a list of project objects with "key" and "name" properties.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectsYes

Implementation Reference

  • Main handler function for the 'projects' tool. Instantiates repository factory, fetches all projects, maps to simplified format, and returns JSON response.
    export async function handleProjects(): Promise<ApiResponse> {
      try {
        const apiKey = getApiKey();
        const repositoryFactory = new RepositoryFactory({ apiKey });
        const projectRepository = repositoryFactory.createProjectRepository();
    
        const handler = createProjectsHandler({
          projectRepository,
          logger,
        });
    
        return handler();
      } catch (error) {
        // Handle configuration errors and other setup issues
        return MCPErrorFormatter.createErrorResponse(error, 'projects-setup');
      }
    }
  • Zod schema definition for the 'projects' tool, specifying name, description, empty input schema, and output as array of project objects with key and name.
    export const projectsToolSchema = {
      name: 'projects',
      description:
        'List all available DeepSource projects. Returns a list of project objects with "key" and "name" properties.',
      inputSchema: {},
      outputSchema: {
        projects: z.array(
          z.object({
            key: z.string(),
            name: z.string(),
          })
        ),
      },
    };
  • Handler wrapper in TOOL_HANDLERS record for 'projects' tool, adds logging and calls the core handleProjects function.
    projects: async (params: unknown) => {
      logger.info('=== PROJECTS HANDLER START ===');
      logger.info('Projects handler called with params:', { params, type: typeof params });
      try {
        // Params currently unused but may be used for future filtering
        const result = await handleProjects();
        logger.info('=== PROJECTS HANDLER SUCCESS ===', { result });
        return result;
      } catch (error) {
        logger.error('=== PROJECTS HANDLER ERROR ===', {
          error,
          message: error instanceof Error ? error.message : String(error),
          stack: error instanceof Error ? error.stack : undefined,
        });
        throw error;
      }
    },
  • Function that registers all tools including 'projects' by creating ToolDefinition from schemas and TOOL_HANDLERS, then calling registry.registerTools.
    export function registerDeepSourceTools(registry: ToolRegistry): void {
      logger.info('=== REGISTER DEEPSOURCE TOOLS START ===');
      logger.info('Registering DeepSource tools', {
        toolSchemasType: typeof toolSchemas,
        toolSchemasIsArray: Array.isArray(toolSchemas),
        toolSchemasLength: Array.isArray(toolSchemas) ? toolSchemas.length : 'not an array',
        toolSchemaNames: Array.isArray(toolSchemas) ? toolSchemas.map((s) => s.name) : 'not an array',
      });
    
      const toolDefinitions: ToolDefinition[] = [];
    
      // Create tool definitions from schemas and handlers
      for (const schema of toolSchemas) {
        logger.debug(`Processing schema: ${schema.name}`);
        const handler = TOOL_HANDLERS[schema.name];
        if (!handler) {
          logger.warn(`No handler found for tool: ${schema.name}`);
          continue;
        }
    
        logger.debug(`Creating tool definition for: ${schema.name}`);
        const toolDef = createToolDefinition(schema, handler);
        toolDefinitions.push(toolDef);
        logger.debug(`Successfully created tool definition for: ${schema.name}`);
      }
    
      logger.info(`Prepared ${toolDefinitions.length} tool definitions for registration`);
    
      // Register all tools
      registry.registerTools(toolDefinitions);
    
      logger.info('=== REGISTER DEEPSOURCE TOOLS COMPLETE ===', {
        registeredCount: toolDefinitions.length,
        registeredTools: toolDefinitions.map((t) => t.name),
      });
    }
Behavior3/5

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 states this is a listing operation (implied read-only) and describes the return format ('list of project objects with key and name properties'), which is helpful. However, it doesn't mention potential limitations like pagination, rate limits, authentication requirements, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly concise with two sentences that each earn their place. The first sentence states the purpose, and the second describes the return format. There's zero wasted language, and the information is front-loaded with the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that this is a simple listing tool with zero parameters, 100% schema coverage, and an output schema exists, the description provides adequate context. It explains what the tool does and what it returns. However, it could be more complete by mentioning when this tool is appropriate versus sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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%. The description appropriately doesn't waste space discussing nonexistent parameters. It focuses instead on the return value, which is appropriate given the parameterless nature of this tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('all available DeepSource projects'), making the purpose immediately understandable. It distinguishes from siblings by focusing on project listing rather than issues, metrics, or runs. However, it doesn't explicitly contrast with specific sibling tools like 'runs' or 'project_issues'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or when other tools like 'project_issues' or 'runs' might be more suitable. It simply states what the tool does without usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sapientpants/deepsource-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server