Provides full CRUD operations for GitHub Projects V2, including managing projects, items, fields, and views through the GitHub API.
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., "@GitHub Projects MCP Server list my projects"
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 Model Context Protocol (MCP) server for GitHub Projects V2. Enables AI assistants to manage GitHub Projects, items, fields, and views through a standardized interface.
Full GitHub Projects V2 Support: Complete CRUD operations for projects, items, fields, and views
Dual Authentication: Support for both Personal Access Tokens (PAT) and GitHub App authentication
User & Organization Projects: Manage projects for both individual users and organizations
17 Specialized Tools: Comprehensive toolset for all project management operations
Type-Safe: Built with TypeScript for complete type safety
Well Tested: 100% unit test coverage
Related MCP server: GitHub Project MCP Server
npm install @lexmata/github-projects-mcpSet your GitHub token as an environment variable:
export GITHUB_TOKEN=ghp_your_personal_access_tokenOr configure GitHub App authentication:
export GITHUB_APP_ID=123456
export GITHUB_APP_PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----..."
export GITHUB_APP_INSTALLATION_ID=12345678Add to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"github-projects": {
"command": "npx",
"args": ["@lexmata/github-projects-mcp"],
"env": {
"GITHUB_TOKEN": "ghp_your_token_here"
}
}
}
}npx @lexmata/github-projects-mcpTool | Description |
| List projects for a user or organization |
| Get detailed project information |
| Create a new project |
| Update project settings |
| Delete a project |
Tool | Description |
| List all items in a project |
| Get item details |
| Add a draft issue to project |
| Add existing issue/PR to project |
| Update a field value on an item |
| Remove an item from project |
Tool | Description |
| List all fields in a project |
| Create a custom field |
| Update field settings |
| Delete a custom field |
Tool | Description |
| List all views in a project |
| Get view details |
Getting Started - Quick start guide
Authentication - Configure GitHub authentication
Tools Reference - Complete tool documentation
Configuration - All configuration options
Examples - Usage examples
repo - Full control of private repositories
project - Full control of projects
Repository permissions:
Issues: Read and write
Pull requests: Read and write
Organization permissions:
Projects: Read and write
Repository permissions:
Issues: Read and write
Pull requests: Read and write
Organization permissions:
Projects: Read and write
Node.js 18+
pnpm 9+
# Clone the repository
git clone https://github.com/Lexmata/github-projects-mcp.git
cd github-projects-mcp
# Install dependencies
pnpm install
# Run tests
pnpm test
# Run tests with coverage
pnpm test:coverage
# Build
pnpm build
# Run in development mode
pnpm devsrc/
├── index.ts # Entry point
├── server.ts # MCP server setup
├── config.ts # Configuration handling
├── auth/ # Authentication providers
├── graphql/ # GraphQL client and queries
├── tools/ # Tool implementations
└── types/ # TypeScript typesContributions are welcome! Please read our Contributing Guide for details on our code of conduct and the process for submitting pull requests.
This project is licensed under the MIT License - see the LICENSE file for details.
Model Context Protocol - The protocol specification
MCP SDK - Official MCP SDK
GitHub Projects API - GitHub GraphQL API documentation
Add a new draft issue to a GitHub Project V2
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The global ID of the project | |
| title | Yes | Title of the draft issue | |
| body | No | Body content of the draft issue | |
| assigneeIds | No | Array of user IDs to assign |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but only says 'Add a new draft issue', giving no information about side effects, permissions, or what happens to the project.
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?
One sentence that is to the point and contains no unnecessary 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?
Adequate for a simple creation tool, but lacks details on return values or behavior; no output schema, but description could still hint at what is returned.
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 coverage is 100%, and all parameters have descriptions in the schema; the description adds no additional meaning beyond what the schema already 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 verb ('Add') and the resource ('draft issue to a GitHub Project V2'), distinguishing it from sibling tools like 'add_existing_issue'.
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 vs alternatives; does not mention that 'add_existing_issue' exists or when to prefer one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an existing issue or pull request to a GitHub Project V2
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The global ID of the project | |
| contentId | Yes | The global ID of the issue or pull request to add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose permissions, side effects (e.g., whether adding modifies the issue), idempotency, or error conditions. For a mutation tool, this is insufficient.
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 with no wasted words. However, it could be slightly expanded to include critical usage context without losing conciseness.
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 complexity (mutation, no output schema) and only 2 parameters, the description lacks context about return values, side effects, and prerequisites. It is too brief to fully guide an AI agent.
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 adds no additional parameter semantics beyond what the schema already provides, such as examples or constraints.
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 (Add) and the resource (existing issue or pull request to a GitHub Project V2). It effectively distinguishes from sibling tool 'add_draft_issue' by specifying 'existing'.
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 guidance on when to use this tool versus alternatives like 'add_draft_issue' or the conditions under which it is appropriate. No when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new custom field in a GitHub Project V2
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The global ID of the project | |
| name | Yes | Name of the field | |
| dataType | Yes | Type of field | |
| singleSelectOptions | No | Options for SINGLE_SELECT fields |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states 'create' without disclosing behavioral traits like idempotency, limits, or authorization 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?
Single sentence with no extraneous words, front-loading the essential information.
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 creation tool with no output schema, description lacks return value info and conditional parameter guidance. Incomplete for agent to fully understand behavior.
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 covers all 4 parameters (100% coverage). Description adds no extra meaning beyond schema, e.g., conditional requirement for singleSelectOptions not mentioned.
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 clearly states the action (create), resource (custom field), and context (GitHub Project V2), distinguishing it from siblings like update_field or delete_field.
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 vs alternatives (e.g., update_field) or prerequisites. Siblings provide related operations but no context given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new GitHub Project V2
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | The username or organization name | |
| ownerType | Yes | Whether the owner is a user or organization | |
| title | Yes | The title of the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as side effects (e.g., creates a project in the specified owner's account), response format, or rate limits.
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?
Single, concise sentence front-loading the purpose. No waste, but overly brief given the tool's complexity and sibling 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?
Lacks essential context for complete agent decision: no output schema, no return value description, no constraints or prerequisites. Incomplete given 3 required parameters and many sibling tools.
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 covers all three parameters with descriptions (100% coverage). The tool description adds no extra semantic meaning beyond the schema.
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 'Create a new GitHub Project V2' clearly states the action (create) and resource (GitHub Project V2). It distinguishes from siblings like 'create_field' but lacks specificity about project type.
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 vs alternatives such as 'add_draft_issue' or 'update_project'. Does not mention prerequisites like authentication scope or required user permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a custom field from a GitHub Project V2
| Name | Required | Description | Default |
|---|---|---|---|
| fieldId | Yes | The global ID of the field to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'delete', which implies mutation, but does not disclose consequences like irreversibility, data loss for items, or required permissions.
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 front-loaded with the verb and resource. No unnecessary words, but could be more informative without increasing length.
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 destructive operation with no output schema or annotations, the description is too terse. It lacks warnings about irreversibility, impact on project items, or success confirmation.
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%: the single parameter 'fieldId' is described as 'The global ID of the field to delete'. The tool description adds no additional semantic meaning beyond the schema, meeting baseline.
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 'Delete', the resource 'custom field', and the scope 'GitHub Project V2'. It distinguishes the tool from siblings like create_field and update_field.
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 the tool vs alternatives, prerequisites (e.g., field must exist), or when not to use it. The description only states what it 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.
Delete a GitHub Project V2
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The global ID of the project to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but adds no behavioral context—no mention of irreversibility, side effects, permissions, or confirmation 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?
Single sentence, front-loaded, no unnecessary words. Every word contributes to meaning.
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 no output schema, the description should provide more context about the result or side effects of deletion. It is insufficient for a safe and informed tool 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?
Schema coverage is 100%, so the schema already describes the parameter. The description adds no extra meaning beyond what the 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 'Delete a GitHub Project V2' uses a specific verb (delete) and resource (GitHub Project V2), clearly distinguishing it from siblings like create_project or delete_field.
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 prerequisites, and no mention of when not to use it. The description solely states the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific GitHub Project V2
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | The username or organization name | |
| ownerType | Yes | Whether the owner is a user or organization | |
| projectNumber | Yes | The project number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'get detailed information,' which implies read-only, but fails to mention any side effects, permissions, rate limits, or response characteristics. This is insufficient for an unannotated 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 clear sentence, front-loaded with the core purpose. No unnecessary words or repetition. Highly concise and efficient.
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 output schema and annotations, the description should provide more context about the return value or behavior. It is minimal and leaves ambiguity about what 'detailed information' entails. Adequate for a simple get tool but could be more 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 coverage is 100% (all 3 parameters described with good detail). The description adds no extra parameter information beyond the schema, so baseline 3 is appropriate. It does not compensate for any gaps but also does not detract.
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 detailed information about a specific GitHub Project V2' clearly states the action (get) and resource (specific GitHub Project V2). It is specific enough for a simple read operation and differentiates from sibling tools like list_projects or get_project_item, though it could be more precise.
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 like get_project_item or get_project_view. The description does not mention any prerequisites or context, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific item in a GitHub Project V2
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The global ID of the project | |
| itemId | Yes | The global ID of the item |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only states 'Get detailed information', which implies a read operation, but does not disclose what 'detailed' includes, return format, or any side effects. More transparency is needed.
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, clear sentence with no wasted words. It is appropriately sized for a simple retrieval tool, though a bit more detail on usage could be added without being verbose.
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 parameters, no output schema, no annotations), the description is fairly complete but lacks behavioral context. It does not specify what 'detailed information' includes or any prerequisites. Adequate but could be improved.
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 coverage is 100%, with both parameters having descriptions in the schema. The description adds no further meaning beyond 'projectId' and 'itemId' IDs. Baseline 3 is appropriate as the schema already documents the parameters adequately.
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 gets detailed information about a specific item in a GitHub Project V2, using a specific verb and resource. It distinguishes from sibling tools like list_project_items (list all) and update_item_field (update).
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 explicit when-to-use or when-not-to-use guidance. The name and description imply it's for retrieving details of a single item, but alternatives are not mentioned. Sibling tools provide context, but the description itself lacks usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific view in a GitHub Project V2
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The global ID of the project | |
| viewNumber | Yes | The view number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Get detailed information,' which implies a read operation but does not confirm read-only behavior, mention required permissions, or describe any side effects. The lack of detail for a read operation reduces 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 a single, concise sentence that effectively communicates the core purpose. It is appropriately front-loaded with the action and resource. Could optionally add more detail without becoming verbose.
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 complexity (two parameters, no output schema, no annotations), the description is somewhat minimal. It does not describe the return value or behavior beyond 'detailed information.' A more complete description would mention what fields are returned or that it supplements list_project_views.
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 coverage is 100%, and both parameters are well-described in the schema. The description adds no additional meaning beyond what the schema already provides, so baseline score 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 action ('Get') and the resource ('detailed information about a specific view in a GitHub Project V2'). This distinguishes it from sibling tools like list_project_views (which lists views) and get_project (which gets the project itself).
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 list_project_views (for enumerating all views) or get_project (for project-level details). The description implies the use case but does not explicitly state context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all fields in a GitHub Project V2
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The global ID of the project | |
| first | No | Number of fields to return (default: 50) | |
| after | No | Cursor for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits beyond listing fields. It fails to mention pagination behavior (though the schema includes 'first' and 'after' parameters), error handling, or performance considerations. The description is too minimal for a tool with no annotations.
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, clear sentence with no filler. It is front-loaded and efficiently communicates the core 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?
Given the tool's simplicity and fully documented parameters, the description is adequate but lacks essential context like usage guidance and behavioral details. It could mention that the return format includes field definitions and that pagination is supported via 'first' and 'after'.
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 covers all three parameters with descriptions (100% coverage), so the description does not need to add much. The tool description itself adds no extra meaning beyond the schema, but the schema handles parameter semantics adequately.
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: listing all fields in a GitHub Project V2. It uses a specific verb ('List') and resource ('fields'), and distinguishes from sibling tools like create_field, delete_field, etc.
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 when to use list_project_items instead. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all items (issues, pull requests, draft issues) in a GitHub Project V2
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The global ID of the project | |
| first | No | Number of items to return (default: 20, max: 100) | |
| after | No | Cursor for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation by stating 'list all items', but it does not explicitly disclose behavioral traits like pagination behavior, authentication requirements, or rate limits. The schema includes pagination parameters, but the description adds no additional 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 a single sentence that is clear and efficient, with no wasted words. It effectively communicates the tool's purpose in a concise manner.
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 3 parameters and no output schema, the description is insufficient. It does not mention the return format, pagination behavior, or any ordering. For a list operation, explaining what items are returned and how pagination works would be necessary for completeness.
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 covers 100% of parameters with descriptions, so the baseline is 3. The description does not add any additional meaning beyond the schema; it only restates the purpose without elaborating on parameters like projectId, first, or after.
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 lists all items (issues, pull requests, draft issues) in a GitHub Project V2. The verb 'list' and resource 'items' are specific, and it implicitly distinguishes from sibling tools like get_project_item (single item) or add_draft_issue (add operation).
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 such as get_project_item or list_projects. The description does not provide context for when this tool is appropriate or when to choose other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List GitHub Projects V2 for a user or organization
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | The username or organization name | |
| ownerType | Yes | Whether the owner is a user or organization | |
| first | No | Number of projects to return (default: 20, max: 100) | |
| after | No | Cursor for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic function and does not disclose behavioral traits like pagination, rate limits, or 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 a single, clear sentence with no unnecessary words. It is front-loaded and efficient.
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 adequate for a simple list operation but lacks details on pagination behavior (even though first and after parameters are in the schema). It does not explain return values, though no output schema is provided.
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 adds no additional meaning beyond the schema; it does not explain parameter usage or relationships.
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 ('List'), the resource ('GitHub Projects V2'), and the scope ('for a user or organization'). This is specific and distinguishes from sibling tools like get_project.
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 when to use the tool (to list projects) but does not provide explicit guidance on when not to use it or mention alternatives such as get_project for single projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all views in a GitHub Project V2
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The global ID of the project | |
| first | No | Number of views to return (default: 20) | |
| after | No | Cursor for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose pagination behavior, ordering, or any other traits. The input schema includes pagination parameters but the description ignores them.
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, clear sentence. It is concise and front-loaded with the essential purpose, but could benefit from a brief mention of pagination.
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 there is no output schema, the description should at least indicate what is returned (list of view objects). It lacks details on the return format and does not compensate for the missing output schema.
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 coverage is 100%, so the description does not need to add parameter details. The description adds no extra meaning beyond what the schema provides, meeting the baseline for this dimension.
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 ('List'), the resource ('views'), and the context ('GitHub Project V2'). It is specific and distinct from sibling tools like get_project_view (single view) or list_project_fields.
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 like get_project_view or list_project_items. The description does not include any context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an item from a GitHub Project V2
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The global ID of the project | |
| itemId | Yes | The global ID of the item to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Remove an item'. It does not disclose whether removal is permanent, requires permissions, has side effects, or what happens to associated data.
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, clear sentence with no unnecessary words. It is appropriately 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 tool, the description lacks important context such as whether the action is reversible, error conditions, or return value. It is too minimal to fully inform an agent.
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?
Both parameters have descriptions in the input schema (100% coverage), so the description adds no extra meaning. 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 action 'Remove an item from a GitHub Project V2', specifying the verb and resource. It distinguishes itself from sibling tools like add_draft_issue or get_project_item.
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. There is no mention of prerequisites, when not to use it, or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a field in a GitHub Project V2
| Name | Required | Description | Default |
|---|---|---|---|
| fieldId | Yes | The global ID of the field | |
| name | Yes | New name for the field |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not state whether the update is destructive, idempotent, or what happens if the fieldId is invalid. The tool updates only the name, but this is already in the schema.
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 waste, but it is so minimal that it borders on under-specification. It earns its place by stating the core purpose, but could be slightly more detailed without losing conciseness.
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 has no output schema and no annotations. The description does not explain what the tool returns (if anything), how it behaves on errors, or any side effects. For a mutation tool, this is incomplete.
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 coverage is 100% (both parameters have descriptions in the schema). The description adds no extra meaning beyond what the schema already provides, so baseline 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 'Update a field' which specifies the verb and resource. However, it does not differentiate from sibling tools like 'create_field' or 'delete_field', though the resource 'field' is specific enough.
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, nor does it mention prerequisites, exclusions, or context. The agent has no help deciding between this and similar tools like 'update_item_field'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a field value on an item in a GitHub Project V2
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The global ID of the project | |
| itemId | Yes | The global ID of the item | |
| fieldId | Yes | The global ID of the field | |
| value | Yes | The value to set |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions the action. It does not disclose side effects (e.g., whether overwrites existing value, whether it triggers notifications), permissions required, or idempotency. The behavioral burden falls entirely on the description, which is insufficient.
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, clear sentence with no extraneous information. It is concise and front-loaded, but could integrate more context without becoming verbose.
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 there is no output schema and no annotations, the description should compensate with richer behavioral context. However, it only provides a minimal statement. For a mutation tool, details like idempotency, confirmation steps, or error handling are missing.
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 all 4 parameters are documented in the input schema. The description does not add additional semantic meaning beyond what the schema already provides, so baseline score of 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 tool name 'update_item_field' and description 'Update a field value on an item in a GitHub Project V2' clearly specify the action (update), target (field value on an item), and platform (GitHub Project V2). It is distinct from sibling tools like 'create_field' and 'update_field'.
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 states what the tool does but does not explicitly guide when to use it versus alternatives (e.g., 'update_field' updates a project field definition, not an item's field value). No exclusion criteria or prerequisite context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a GitHub Project V2 (title, description, readme, visibility, or closed status)
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The global ID of the project | |
| title | No | New title for the project | |
| shortDescription | No | New short description | |
| readme | No | New readme content | |
| closed | No | Whether to close the project | |
| public | No | Whether the project is public |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks details on side effects (e.g., permission requirements, atomicity, impact of closing or changing visibility). Fails to disclose behavioral traits beyond the listed fields.
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?
Single sentence, front-loaded with key information, 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?
For a mutation tool with 6 parameters and no output schema, the description does not explain the return value, validation behavior, or what happens when multiple fields are updated simultaneously. Incomplete for an agent to fully understand the 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 coverage is 100%, and description lists the same fields already described in the schema. Adds no additional syntax, format, or usage details beyond what the 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?
Description clearly states the verb 'update' and the resource 'GitHub Project V2', listing specific updatable fields. It distinguishes from sibling tools like create_project and delete_project.
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?
Description implies use for updating but does not explicitly state when to use it versus alternatives. No exclusions or prerequisites are mentioned.
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.0add_draft_issueadd_existing_issuecreate_fieldcreate_projectdelete_fielddelete_projectget_projectget_project_itemget_project_viewlist_project_fieldslist_project_itemslist_project_viewslist_projectsremove_project_itemupdate_fieldupdate_item_fieldupdate_projectEach tool targets a distinct resource or action within GitHub Projects V2, with clear boundaries. For example, adding draft issues and adding existing issues are clearly differentiated by description, and all other tools have unique purposes.
All tools follow a consistent verb_noun pattern in snake_case, such as create_project, list_project_items, and update_item_field. The use of 'add' for issues vs 'create' for fields and projects is a minor convention shift but still logically consistent.
17 tools is appropriate for a comprehensive GitHub Projects V2 management server. The tool count covers all major CRUD operations for projects, fields, items, and views without being excessive.
The tool set covers most important workflows: creating, reading, updating, and deleting projects, fields, and items. However, it lacks tools for creating, updating, or deleting views, and there is no dedicated tool to get a specific field by ID (only list). These are minor gaps but do not severely hinder core functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Access the GitHub API, enabling file operations, repository management, search functionality, and…
Project management for teams and their AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Lexmata/github-projects-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
