Claude Code Connector MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| projects-config | No | Path to the projects configuration file | ~/.claude/projects.json |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| register_projectC | Register a project directory for Claude Code Connector access |
| list_projectsC | List all registered projects with status |
| write_to_projectC | Write content to a file in registered project directory |
| read_from_projectC | Read file content from registered project |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose with no overlap: list_projects enumerates projects, register_project adds new ones, read_from_project retrieves file content, and write_to_project modifies files. The actions (list, register, read, write) and targets (projects vs. files) are well-differentiated, leaving no ambiguity for agent selection.
All tools follow a consistent verb_noun pattern with underscores: list_projects, register_project, read_from_project, write_to_project. The naming is uniform and predictable, making it easy for agents to infer functionality from the names alone without deviation or mixed conventions.
With 4 tools, the set is well-scoped for the server's purpose of managing projects and files in the Claude Code Connector. Each tool earns its place by covering essential operations (listing, registering, reading, writing), avoiding bloat or thinness, which is ideal for a focused utility server.
The tool surface provides complete CRUD/lifecycle coverage for the domain: register_project (create), list_projects (read/list), read_from_project (read content), and write_to_project (update). There are no obvious gaps for managing projects and files, ensuring agents can handle core workflows without dead ends.