mcp-github-enterprise

List organizations

list_organizations

Read-onlyIdempotent

Discovers organizations visible to the token, filters them by the enterprise allowlist, and flags protected organizations so you can identify valid org logins for read-only administration.

Instructions

List the organizations the token can see (filtered by GHE_ORG_ALLOWLIST), each flagged if it is protected (readable but never mutated). Start here to discover valid org logins.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_organizations"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Nov 7, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), so the description earns credit for adding things the annotations cannot: results are filtered by GHE_ORG_ALLOWLIST, and the protected flag means readable but never mutated. That discloses auth/allowlist scoping and a non-obvious field semantic. It stops short of 5 by not mentioning pagination or whether all orgs are returned at once.

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?

Two compact sentences, zero padding, and the scope/allowlist constraint plus the routing hint are both front-loaded. Every clause carries information an agent would otherwise have to infer.

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

Completeness5/5

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

With no input parameters and no output schema, the description carries the burden of explaining the result shape, and it does so by stating that each org is flagged for protection. Combined with the allowlist scoping and the discovery-purpose hint, an agent has enough to call it and interpret its output.

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 takes zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. Nothing in the description misleads about inputs.

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 uses a specific verb and resource ("List the organizations") and narrows scope to what the token can see, which is meaningfully different from the sibling get_organization that fetches one org. It does not explicitly name a contrasting sibling, so it falls short of a 5.

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?

"Start here to discover valid org logins" gives concrete entry-point guidance and implies this should precede calls like get_organization, list_repositories, or assess_org_posture. It states the positive case clearly but gives no explicit when-not-to-use condition.

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