Feature Request: `get_agent_card` tool — load ALP-compatible agents directly from GitHub repos

[RodrigoMvs123]

Summary

Add a get_agent_card tool to the GitHub MCP Server that reads an
agent.alp.json file from any repository and returns it as a parsed,
schema-validated JSON object.

This closes the last gap between an agent living in a GitHub repo and that agent being live in any MCP-compatible runtime (Kiro, Claude Code, Claude Desktop, VS Code, Cursor) — in one tool call.

---

Background: what ALP is

Agent Load Protocol (ALP) is an open, MCP-compatible format for describing complete AI agents as a single portable artifact — the Agent Card (agent.alp.json).

What MCP is to tools, ALP is to entire agents.

An Agent Card declares:

• id, name, description — agent identity
• persona — the full system prompt
• tools[] — MCP-compatible tool endpoints (local or proxied HTTP)
• memory — session/persistent memory config
• llm — provider preference (any, user-resolved)
• server.url + server.transport — where the ALP Server lives
• toolsets, security.read_only, pagination — runtime control fields
  (mirrors concepts already in the GitHub MCP Server)

Current version: v0.7.0

Spec + reference implementation:
https://github.com/RodrigoMvs123/agent-load-protocol

Live demo MCP endpoint:
https://agent-load-protocol.onrender.com/mcp

Any MCP host can load the live demo agent today with:

{
  "mcpServers": {
    "hello-agent": {
      "type": "http",
      "url": "https://agent-load-protocol.onrender.com/mcp"
    }
  }
}

---

The gap this tool closes

The GitHub MCP Server already has get_file_contents, which can read any file from a repo — including agent.alp.json.

However, it returns a raw base64-encoded blob. The caller must:

• Decode
• JSON-parse
• Validate manually

before the agent can be used.

get_agent_card would instead return a typed, schema-validated JSON object directly usable by any ALP-aware runtime.

This is the difference between GET /blob and GET /agent — structured semantics vs raw bytes.

---

Proposed tool

Tool name: get_agent_card
Toolset: repos (existing) — or a new lightweight alp toolset
Required OAuth scope: repo (same as get_file_contents)

Input parameters

Parameter	Type	Required	Description
owner	string	yes	Repository owner
repo	string	yes	Repository name
ref	string	no	Branch, tag, or commit SHA (defaults to repo default branch)
path	string	no	Path to the card file (defaults to agent.alp.json at repo root)

Output (parsed Agent Card object)

{
  "alp_version": "0.7.0",
  "id": "my-agent",
  "name": "My Agent",
  "persona": "You are a helpful assistant.",
  "tools": [
    {
      "name": "search",
      "description": "Search the knowledge base.",
      "endpoint": "https://my-server.com/api/search"
    }
  ],
  "server": {
    "url": "https://my-alp-server.com",
    "transport": "http"
  },
  "llm": { "provider": "any" },
  "memory": { "enabled": false }
}

If agent.alp.json is not found at the given path, the tool returns a clear error.
If the file exists but fails ALP schema validation, the tool returns a validation error identifying the offending fields.

---

How it unlocks the full GitHub → Kiro flow

With this tool approved and shipped, the end-to-end flow becomes:

Developer commits agent.alp.json to any GitHub repo
↓
Kiro (or any MCP host) calls get_agent_card { owner, repo }
↓
GitHub MCP Server fetches + parses + validates the card
↓
ALP runtime (Kiro) reads persona → injects into LLM context
ALP runtime reads tools[] → registers MCP-compatible endpoints
↓
Agent is live in the Kiro chat window

No local clone. No manual config. One tool call.

This is the scenario that ALP's remote card mode (v0.6.0) was designed for:

• Ship agent.alp.json in your GitHub repo
• Point a runtime at it
• Agent is live

The GitHub MCP Server is the natural discovery bridge — it already sits between GitHub and every major IDE.

get_agent_card completes that bridge.

---

Alignment with existing GitHub MCP Server patterns

GitHub MCP Server feature	ALP equivalent
--toolsets flag / GITHUB_TOOLSETS env var	ALP toolsets.groups + toolsets.active
--read-only flag	ALP security.read_only + per-tool readonly: false
--dynamic-toolsets beta	ALP tools_discovery.mode: "dynamic"
server.json manifest at repo root	ALP server.alp.json manifest at server root
--insiders / insiders URL	ALP server.channel: "insiders" + insiders_url
Tool description env-var overrides	ALP description_override_key per tool
Deprecated tool aliases	ALP tools[].aliases + tools[].deprecated

ALP modeled several of these fields directly from the GitHub MCP Server architecture.

get_agent_card is a natural extension in the same direction.

---

Implementation sketch

// In pkg/github/repos.go (or a new alp.go file in the repos toolset)

func GetAgentCard(owner, repo, ref, path string) (*ALPCard, error) {
    // 1. Resolve path (default: "agent.alp.json")
    // 2. Call existing GetFileContents(owner, repo, path, ref)
    // 3. Decode base64 content
    // 4. json.Unmarshal into ALPCard struct
    // 5. Validate alp_version field is present and semver-parseable
    // 6. Return parsed struct (or validation error)
}

The implementation wraps get_file_contents — no new GitHub API calls needed.

ALP JSON schema:
https://github.com/RodrigoMvs123/agent-load-protocol/blob/main/schema/agent.alp.schema.json

---

Optional: server.alp.json companion endpoint

ALP v0.3.0+ defines a server.alp.json manifest that ALP-aware clients read before the full agent card to understand server capabilities:

• Supported transports
• Auth methods
• Available channels

A companion tool:

• get_alp_server_manifest
  or
• include_server_manifest (boolean flag on get_agent_card)

would surface this in one call.

This mirrors the GitHub MCP Server’s own server.json at the repo root.

---

Considered alternative: use get_file_contents directly

Yes, get_file_contents already works. A client can:

• Fetch file
• Decode base64
• Parse JSON manually

However, a dedicated tool is still valuable:

1. Structured output — returns a typed object, not a blob
2. Schema validation — catches malformed cards early
3. Discoverability — get_agent_card is self-explanatory
4. Default path resolution — encodes agent.alp.json convention
5. Future-proofing — centralizes validation logic

---

References

• ALP repository:
  https://github.com/RodrigoMvs123/agent-load-protocol

• ALP live MCP endpoint:
  https://agent-load-protocol.onrender.com/mcp

• ALP JSON schema:
  https://github.com/RodrigoMvs123/agent-load-protocol/blob/main/schema/agent.alp.schema.json

• ALP SPEC.md:
  https://github.com/RodrigoMvs123/agent-load-protocol/blob/main/SPEC.md

• ALP pip library (v0.7.0):
  pip install alp-server