Skip to main content
Glama
shubhtoy

github-project-info-mcp

by shubhtoy
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

github-project-info-mcp

CI npm version License: MIT Node >=18 MCP

An MCP server for reading public GitHub Projects (v2) boards without authentication — including item-level data (status, custom fields, story points) for boards that GitHub's own official API can't read unauthenticated.

Runs entirely locally via stdio (npx -y github-project-info-mcp, no server, no Cloudflare, no infrastructure of any kind) — this is the primary, standard way to use it. A browser client and a self-hostable Cloudflare Worker are also included as optional extras for the specific case of calling this from client-side JavaScript (see Browser usage); neither is needed for normal MCP usage and neither is a runtime dependency of the stdio server.

Also ships as an Agent Skill — see Skill below.

Why this exists

GitHub's official REST API for Projects v2 has an authentication gap:

Endpoint

Org-owned project

User-owned project

Project metadata (title, state, dates)

✅ unauthenticated for public projects

✅ unauthenticated for public projects

Project items (status, fields, points)

✅ unauthenticated for public projects

❌ 401, even when the project is public

This is confirmed live against GitHub's current API, not just inferred from docs — see docs/investigation.md for the full trail. If your project board is owned by your personal GitHub user account (the common case for solo/personal projects), there is no official, documented, unauthenticated way to read its items.

This library closes that gap for user-owned projects using a public fallback: the project board's own webpage embeds full item data as JSON, unauthenticated, for any public project. This tool reads that instead.

Related MCP server: GitHub Projects MCP Server

What's official vs. unofficial

  • get_project_metadata — uses GitHub's official, documented REST API (GET /users|orgs/{owner}/projectsV2/{n}). Stable, unauthenticated, works for any public project.

  • list_project_items — for org-owned projects, uses GitHub's official REST API (unauthenticated for public projects, per GitHub's docs). For user-owned projects, falls back to reading the public board page's embedded JSON (<script id="memex-paginated-items-data">). This fallback is undocumented and unofficial — it depends on GitHub's current page markup, not a published API contract, and could break without notice if GitHub changes it.

  • get_project_item — fetches a single item via an internal endpoint GitHub's own web UI uses (github.com/memexes/{projectId}/items). Returns every field on the project, including custom fields (Priority, Story Points) that the bulk list_project_items above can't see. Also undocumented and unofficial, same caveats as above.

Use this if you need it and understand the tradeoff. If GitHub ever publishes an official unauthenticated items API for user-owned projects, switch to that instead — this project would then be unnecessary for that use case.

Installation

As an MCP server (standard path): the conventional way to distribute and run an MCP server is via npm + npx, so it can be launched with no manual clone/build step:

npx -y github-project-info-mcp

(Requires the package to be published to npm first — see Publishing if you're maintaining a fork.)

From source (for development, or to use the library/Worker/browser-client parts):

git clone https://github.com/shubhtoy/github-project-info-mcp.git
cd github-project-info-mcp
npm install
npm run build

Usage as an MCP server

Add to your MCP client config (Claude Desktop, Kiro, etc.):

{
  "mcpServers": {
    "github-project-info": {
      "command": "npx",
      "args": ["-y", "github-project-info-mcp"]
    }
  }
}

Or, running from a local clone instead of the published package:

{
  "mcpServers": {
    "github-project-info": {
      "command": "node",
      "args": ["/path/to/github-project-info-mcp/dist/index.js"]
    }
  }
}

Tools

  • get_project_metadata(ownerType, owner, projectNumber) — project title, description, state, dates.

  • list_project_items(ownerType, owner, projectNumber) — all items with their fields (status, labels, sub-issue progress, etc — whatever's visible in the board's default view). Status/select field values are resolved to human-readable names automatically for user-owned projects. Custom fields outside the default view (Priority, Story Points, etc) are not included here — use get_project_item for those.

  • get_project_item(projectId, itemId, owner?, projectNumber?) — single item's full field data, including custom fields (Priority, Story Points, etc) that list_project_items doesn't return — confirmed live: the bulk endpoint only reflects the board's active view, while this per-item endpoint returns every field defined on the project. Get projectId from get_project_metadata's id field (the plain numeric database ID — NOT nodeId, the GraphQL node ID, which does not work with this endpoint), and itemId from list_project_items. Pass owner/projectNumber too to resolve custom field names and single-select option names (adds one extra request); omit them to get raw field/option IDs instead.

  • get_project_fields(owner, projectNumber) — field definitions for a user-owned project, including single-select option names/colors (e.g. Status: Todo/In Progress/Done) and saved views.

  • list_user_projects(username) — list all public projects owned by a user account. There's no official API for this at all (Projects aren't a GitHub Search API resource type); this reads the user's profile page Projects tab.

Browser usage (no server, no deploy required)

None of the fallback endpoints this library calls send Access-Control-Allow-Origin, so a browser can't call them directly — see CORS note. src/browser-client.ts solves this with zero setup by default, routing through a free public CORS proxy (AllOrigins):

import { getProjectItemsBrowser, getProjectMetadataBrowser } from 'github-project-info-mcp/browser'

const metadata = await getProjectMetadataBrowser('users', 'someuser', 4) // no proxy needed — official API already sends CORS headers
const items = await getProjectItemsBrowser('someuser', 4) // routed through the public proxy by default

This works immediately, no account or deploy needed. The tradeoff: you're depending on a third-party proxy service — it's rate-limited and its uptime isn't guaranteed. Fine for prototyping, demos, or low-traffic pages.

Upgrade path: self-hosted Worker (more reliable, still free)

For anything you need to be reliable, deploy your own instance instead — same free tier, but you own it. See Deploying your own instance below for the full steps; once deployed, pass the URL to the browser client instead of using the default proxy:

const items = await getProjectItemsBrowser('someuser', 4, {
  workerBaseUrl: 'https://your-worker.workers.dev',
})

Or call the Worker's HTTP API directly:

GET /users/:username/projects
GET /projects/:owner/:number/metadata?ownerType=user|org
GET /projects/:owner/:number/items?ownerType=user|org
GET /projects/:owner/:number/fields

No secrets or environment variables are needed for either path — every endpoint involved is public and unauthenticated by design.

Skill

This repo also ships SKILL.md, following the Agent Skills format, so agents (Claude, Kiro, etc.) that support skills can discover when and how to use this MCP server automatically — install via skills.sh (npx skills add shubhtoy/github-project-info-mcp) or by pointing an agent at this repo directly.

Publishing (maintainers)

Publishing to npm is the standard distribution path for MCP servers — once published, anyone can run npx -y github-project-info-mcp with no clone/build step. To publish a new version:

npm version patch   # or minor/major — bumps package.json AND creates a local git tag
git push --tags
npm publish
gh release create v$(node -p "require('./package.json').version") --generate-notes

npm version already creates the git tag; git push --tags (or git push --follow-tags) pushes it, and gh release create turns it into a GitHub Release with auto-generated notes from commits since the last tag (edit them afterward for a cleaner summary if needed).

The files field in package.json is already scoped to ship only dist/, README.md, and LICENSE — no source, tests, or dev config get published. prepublishOnly isn't currently wired to auto-build; run npm run build before publishing, or add that hook if you want it enforced.

There's also an official MCP Registry (in preview as of writing) for centralized discovery across clients — worth publishing there too once this package is stable, via the mcp-publisher CLI.

(Optional) Deploying your own Cloudflare Worker

Not needed for standard MCP usage — this only matters if you want the browser client to skip the public proxy dependency (see Browser usage above), or want a remote (non-stdio) MCP endpoint. Nothing in this section is required to run the server via npx github-project-info-mcp or any normal MCP client config.

A demo instance is deployed for quick testing (not an SLA'd service — it's a personal Cloudflare account's free tier, could go away or hit rate limits with heavy use; deploy your own per below for anything you depend on):

  • CORS-proxy HTTP API: https://github-project-info-api.shubhmittal-sm.workers.dev

  • Remote MCP server: https://github-project-info-mcp.shubhmittal-sm.workers.dev/mcp

To deploy your own instead:

npx wrangler login      # one-time, opens a browser to authorize a free Cloudflare account
npm run worker:deploy       # deploys the CORS-proxy HTTP API
npm run mcp-worker:deploy   # deploys the remote MCP server (Streamable HTTP, at /mcp)

Both deploy independently to Cloudflare's free tier (100,000 requests/day each, no credit card required) and print your live *.workers.dev URL on success. Test locally first with npm run worker:dev / npm run mcp-worker:dev before deploying.

Usage as a library

import { getProjectMetadata, listProjectItems } from 'github-project-info-mcp/client'

const metadata = await getProjectMetadata('users', 'someuser', 4)
const { items } = await listProjectItems('users', 'someuser', 4)

CORS note

Only the fallback endpoints for user-owned project items lack CORS headers (the board-page scrape, the memex per-item endpoint) — that's the whole reason browser-client.ts and worker.ts exist; see Browser usage above for the two ways to work around it. GitHub's official metadata endpoint already sends Access-Control-Allow-Origin: * and needs no proxy.

Limitations

  • Only works for public projects. Private projects need real authentication — use GitHub's official API/SDK/CLI for those.

  • The user-owned-items fallback depends on undocumented GitHub internals and may stop working if GitHub changes its page structure. If it breaks, please open an issue — this repo will be updated if a fix or better path is found.

  • Board-scrape pagination: the board page returns whatever items are in GitHub's default view for that project. If a project has items excluded from the default view (e.g. archived, or filtered out by a saved view), they won't appear via this path.

Security

Dependencies are pinned to versions with known npm audit advisories patched (checked at the time of writing — re-run npm audit yourself before relying on this in anything sensitive). Notably @modelcontextprotocol/sdk is pinned to 1.29.0+, which patches a DNS-rebinding- protection gap (CVE-2025-66414) — that specific advisory affects unauthenticated localhost-bound HTTP servers using the SDK's raw transport classes directly; this repo's worker-mcp.ts runs on Cloudflare Workers (not localhost) via the agents package's own WorkerTransport, a different code path, so the advisory's exact preconditions likely don't apply here — noted for transparency, not as a claim this repo was specifically audited against it.

License

MIT

Available Tools

5 tools
get_project_fieldsA

Get a public GitHub Projects (v2) board's field definitions — including single-select field option names/colors (e.g. Status: Todo/In Progress/Done) and saved views. Useful for resolving the option IDs found in list_project_items results to human-readable names. Currently only supported for user-owned projects (uses the same board-page data source as list_project_items for those).

ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesGitHub username that owns the project
projectNumberYesThe project number, e.g. 4 for .../projects/4

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits. It adds useful context about public access and user-owned project support, and references the same data source as list_project_items. However, it does not explicitly state the operation is read-only or describe return format/pagination, leaving gaps in the behavioral disclosure.

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

Conciseness4/5

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

The description is reasonably sized with a clear front-loaded purpose. The additional details about use case and limitation are valuable and each sentence earns its place, though it could be slightly tightened.

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?

For a simple two-parameter getter with no annotations or output schema, the description covers purpose, return contents (field definitions, option colors, saved views), a use case, and limitations. It doesn't explain response structure or failure modes, but the current information is sufficient for most invocation scenarios.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully describes both parameters (owner and projectNumber) with 100% coverage. The description adds an extra constraint (user-owned, public) but doesn't elaborate on parameter formats or semantics beyond the schema, so it meets but doesn't exceed the baseline for high schema coverage.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Get a public GitHub Projects (v2) board's field definitions.' It also details what's included (single-select options, saved views) and a concrete use case (resolving option IDs), distinguishing it from sibling tools like get_project_metadata.

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

Usage Guidelines4/5

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

It provides clear usage context: it's useful for resolving option IDs from list_project_items, and it notes a limitation (user-owned projects only). However, it doesn't explicitly name alternative tools or state when not to use it, so it falls short of explicit exclusions.

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

get_project_itemA

Get full field data for a single item in a public GitHub Projects (v2) board — including custom fields (like Priority, Story Points) that list_project_items may not show, since that only returns the board's default-view columns while this returns every field defined on the project. Requires the project's numeric database ID (from get_project_metadata's id field — NOT nodeId, which does not work with this endpoint) and the item's numeric ID (from list_project_items). Pass owner and projectNumber too so custom field names and single-select option names (e.g. a Status ID resolved to "Done") can be resolved — omit them to get raw field IDs/option IDs instead, skipping an extra request. Uses an unofficial, undocumented GitHub endpoint — works today for public projects but is not a published API contract.

ParametersJSON Schema
NameRequiredDescriptionDefault
ownerNoGitHub username that owns the project, for resolving custom field/option names
itemIdYesThe numeric item ID, from list_project_items
projectIdYesThe project's numeric database ID, from get_project_metadata's `id` field
projectNumberNoThe project number, for resolving custom field/option names

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that the tool uses an 'unofficial, undocumented GitHub endpoint' and that it 'works today for public projects but is not a published API contract,' setting clear expectations about reliability. It also mentions the nodeId incompatibility and the ID-resolution behavior, adding significant transparency beyond the annotation baseline.

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?

Though long, every sentence contributes: purpose, differentiation, required IDs, optional parameter behavior, and reliability caveat. The structure front-loads the core action, then explains dependencies and trade-offs, ending with a crucial warning. No superfluous content.

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?

The description explains what the tool does, how it differs from siblings, ID requirements, and optional parameter effects, which is substantial without an output schema. However, it does not explicitly describe the shape of the returned data (e.g., whether it returns a flat object or nested fields), leaving a minor gap for a 'get' operation. Still, given the complexity and the tool's nature, it's nearly complete.

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?

Schema covers 100% of parameters, so baseline is 3. The description adds important context: projectId must come from get_project_metadata's `id` field and not nodeId, itemId from list_project_items, and owner/projectNumber are only needed for resolving custom field/option names (omit to get raw IDs). This clarifies parameter relationships and usage, going beyond schema descriptions.

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

Purpose5/5

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

Description clearly identifies the verb ('Get') and specific resource ('full field data for a single item in a public GitHub Projects (v2) board'), and explicitly distinguishes itself from list_project_items by noting it returns every field defined on the project instead of only default-view columns. The mention of custom fields like Priority/Story Points provides concrete examples.

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

Usage Guidelines5/5

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

The description states when to use this tool: when needing full field data including custom fields, and contrasts with list_project_items which only returns default-view columns. It also gives explicit instructions on required IDs (numeric, not nodeId) and optional parameters (owner/projectNumber) with clarifications on what happens if omitted. This effectively guides selection among the sibling tools.

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

get_project_metadataA

Get metadata (title, description, state, dates) for a public GitHub Projects (v2) board. Works unauthenticated for both user-owned and org-owned public projects.

ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesGitHub username or organization name that owns the project
ownerTypeYesWhether the project is owned by a personal GitHub user account or an organization
projectNumberYesThe project number, e.g. 4 for .../projects/4

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden for behavioral disclosure. It explicitly states unauthenticated access and that it applies only to public projects, which are key constraints. It does not mention error handling or response structure, but these are less critical for a read-only metadata fetch.

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 two sentences with no filler. It front-loads the purpose and packs the access scope into the second sentence, making every word useful.

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?

The description conveys what the tool returns (metadata fields), its scope (public, user/org owned), and auth requirement (unauthenticated), covering the essentials. The lack of an output schema is mitigated by the explicit list of metadata fields, though error behavior is not addressed.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides complete descriptions for all three parameters (coverage 100%), so the description does not need to add parameter-level detail. The description only adds context about the return fields, not about the parameters themselves, fitting the baseline of 3.

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

Purpose5/5

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

The description uses a specific verb 'Get' and clearly identifies the resource as metadata for a GitHub Projects v2 board. It enumerates the metadata fields (title, description, state, dates) and distinguishes itself from sibling tools like get_project_fields (fields) and get_project_item (single item).

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

Usage Guidelines4/5

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

The description specifies that it works unauthenticated for public projects, which gives clear context on when it can be used. However, it does not explicitly contrast it with sibling tools or state when not to use it, so it stops short of a 5.

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

list_project_itemsA

List all items (issues/PRs/draft issues) in a public GitHub Projects (v2) board, including their status, custom field values, and other metadata. For org-owned projects this uses GitHub's official REST API. For user-owned projects, GitHub's official API requires authentication even for public projects, so this falls back to reading the public board page's embedded data — an unofficial method that could break if GitHub changes its page structure.

ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesGitHub username or organization name that owns the project
ownerTypeYesWhether the project is owned by a personal GitHub user account or an organization
projectNumberYesThe project number, e.g. 4 for .../projects/4

TDQS

A4.4/5.0
Behavior4/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 explicitly reveals that for user-owned projects it falls back to an unofficial page-scraping method that 'could break if GitHub changes its page structure'—a critical risk that an agent must know. It does not mention pagination or return format, but the core behavioral trait is well exposed.

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 consists of two sentences: the first states the core purpose and result content, and the second provides the essential implementation caveat. Every sentence earns its place with no redundant or filler phrasing.

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?

With no output schema and no annotations, the description must convey enough context for safe invocation. It covers the purpose, result contents, and a major behavioral difference between owner types. Gaps include pagination behavior and error conditions for private/non-existent projects, but for a listing tool with fully documented parameters this is acceptably complete.

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 schema already covers all 3 parameters at 100%, so baseline is 3. The description adds meaning to the 'ownerType' parameter by explaining that 'user' triggers the unofficial fallback while 'org' uses the official REST API, which is not obvious from the schema alone. This extra context helps the agent predict behavior per owner type.

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

Purpose5/5

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

The description uses the specific verb 'List' with a clear resource: 'all items (issues/PRs/draft issues) in a public GitHub Projects (v2) board'. It enumerates the output contents (status, custom field values, metadata), which distinguishes it from siblings like get_project_item (single item) and get_project_fields (schema).

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

Usage Guidelines4/5

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

The description clearly implies this is the tool for listing all items in a public project board, and it provides contextual guidance on the behavioral split between org-owned and user-owned projects. However, it does not explicitly state 'when not to use this' or name alternative tools, though siblings are obvious.

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

list_user_projectsA

List all public GitHub Projects (v2) boards owned by a user account. There is no official GitHub API for this (Projects aren't a Search API resource type, and the REST API requires already knowing a project number) — this reads the same project list shown on a user's profile page (the Projects tab).

ParametersJSON Schema
NameRequiredDescriptionDefault
usernameYesGitHub username

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries the full burden. It discloses that the tool reads the same project list from the user's profile page, and explains the limitation of the official APIs. This is useful behavioral context beyond the schema, though it does not discuss authentication, rate limits, or output format.

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 composed of two concise sentences. The first states the primary purpose; the second adds essential context about the API limitation. Every word earns its place, with no redundant information.

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?

For a one-parameter tool with no output schema, the description is sufficiently complete. It explains what the tool does, the source it reads from, and why it exists. A minor omission is the lack of an explicit note on the return format, but that is not critical for this use case.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage with the parameter 'username' described as 'GitHub username'. The description does not add additional semantics beyond that, but none are needed for such a simple parameter. Baseline of 3 applies.

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

Purpose5/5

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

The description clearly states the action ('List') and the specific resource ('public GitHub Projects (v2) boards owned by a user account'). It also distinguishes from sibling tools by focusing on the user-level listing, which is the entry point to other project-related tools.

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

Usage Guidelines4/5

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

The description implicitly explains when to use this tool: when you need to list a user's projects without knowing a project number. It also provides helpful context about the lack of an official API, which justifies the tool's existence. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to decide.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updatesv0.1.3
    • First observedget_project_fields
    • First observedget_project_item
    • First observedget_project_metadata
    • First observedlist_project_items
    • First observedlist_user_projects
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: project metadata, field definitions, listing projects, listing items, and getting a single item's detail. There is no meaningful overlap, and the descriptions further clarify the boundaries.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: get_project_metadata, get_project_fields, list_user_projects, list_project_items, get_project_item. The verbs are uniformly 'get' or 'list' and nouns are specific and clear.

Tool Count5/5

Five tools is well-scoped for a read-only GitHub Projects v2 info server. Each tool covers a distinct aspect of the domain without redundancy or bloat.

Completeness3/5

The server covers core read operations (metadata, fields, item list, item detail) but has notable gaps: there is no way to list org-owned projects (only user-owned), and get_project_fields is not supported for org-owned projects. These gaps limit workflows for projects owned by organizations.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

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/shubhtoy/github-project-info-mcp'

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