Rockachopa/Timmy-time-dashboard
1
0
Fork 2
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Add Gitea MCP client for autonomous PR workflow #34

Closed
Rockachopa wants to merge 0 commits from feat/gitea-mcp-integration into main
pull from: feat/gitea-mcp-integration
merge into: Rockachopa:main
Conversation 2 Commits - Files Changed -
Rockachopa commented 2026-03-14 14:18:10 +00:00
Owner
Copy Link

Adds GiteaMCPClient class to enable Timmy to autonomously manage repositories, create PRs, and manage issues via the Gitea API.

This enables the daily scheduled workflow for autonomous improvements.

Adds GiteaMCPClient class to enable Timmy to autonomously manage repositories, create PRs, and manage issues via the Gitea API. This enables the daily scheduled workflow for autonomous improvements.
Rockachopa added 1 commit 2026-03-14 14:18:10 +00:00
feat: Add Gitea MCP client for autonomous PR workflow
Some checks failed
Tests / lint (pull_request) Failing after 4s
Details
Tests / test (pull_request) Has been skipped
Details
e2e4cbfe1d
hermes requested changes 2026-03-14 14:38:16 +00:00
hermes left a comment
Collaborator
Copy Link

Code Review: PR #34 — Gitea MCP Client for Autonomous PR Workflow

Verdict: REQUEST CHANGES — this duplicates existing functionality and has implementation issues.

Core Problem: This Already Exists

The project already has a working Gitea MCP integration at src/timmy/mcp_tools.py (279 lines). It:

  • Uses Agno's MCPTools with StdioServerParameters
  • Connects to the actual gitea-mcp binary at ~/go/bin/gitea-mcp
  • Reads config from settings.gitea_token / settings.gitea_url
  • Handles issue creation, repo ops, PR tools
  • Is already wired into the agent via create_gitea_mcp_tools()

This PR adds a second, completely independent Gitea client (gitea_mcp_client.py) that reimplements the same functionality with a hand-rolled JSON-RPC subprocess approach. Nothing in the codebase imports or references it.

Implementation Issues

1. Hand-rolled MCP protocol is fragile

The call_tool() method (lines 87-126) implements bare JSON-RPC over stdin/stdout:

  • Hardcodes "id": 1 for every request — concurrent calls would collide.
  • Uses readline() which will deadlock if the server sends multi-line responses or doesn't terminate with newline.
  • No MCP protocol initialization (the spec requires a handshake before tool calls).
  • No handling of MCP notifications or server-initiated messages.

The existing code uses Agno's MCPTools which handles all of this correctly.

2. No __del__ or context manager — process leak

If the GiteaMCPClient object is garbage collected without calling stop(), the subprocess is orphaned. Should be a context manager (__enter__/__exit__) or use atexit.

3. get_repo() is O(n) — lists all repos to find one

Lines 133-139 call list_my_repos then linear-scans for a match. The Gitea MCP server has direct repo lookup tools.

4. Bare except Exception in start()

Line 72-73 catches all exceptions. This is one of the issues already filed against the codebase (#25).

5. Assumes tool response shape without verification

Methods like list_repos() assume result.get("repositories", []) and list_pull_requests() assumes result.get("pull_requests", []) — but these response shapes aren't documented in the MCP spec. The actual gitea-mcp tool returns content blocks, not structured dicts.

6. No tests

227 lines of new code, zero tests.

Recommendation

Close this PR. The functionality already exists in mcp_tools.py and is properly integrated with the Agno framework the project uses. If Manus needs to interact with Gitea for his daily PRs, he should use the Gitea REST API directly (which he's already doing to push branches and create PRs via the token), not add a second MCP client.

— Hermes

## Code Review: PR #34 — Gitea MCP Client for Autonomous PR Workflow **Verdict: REQUEST CHANGES — this duplicates existing functionality and has implementation issues.** --- ### Core Problem: This Already Exists The project already has a working Gitea MCP integration at `src/timmy/mcp_tools.py` (279 lines). It: - Uses Agno's MCPTools with StdioServerParameters - Connects to the actual `gitea-mcp` binary at `~/go/bin/gitea-mcp` - Reads config from `settings.gitea_token` / `settings.gitea_url` - Handles issue creation, repo ops, PR tools - Is already wired into the agent via `create_gitea_mcp_tools()` This PR adds a second, completely independent Gitea client (`gitea_mcp_client.py`) that reimplements the same functionality with a hand-rolled JSON-RPC subprocess approach. Nothing in the codebase imports or references it. --- ### Implementation Issues **1. Hand-rolled MCP protocol is fragile** The `call_tool()` method (lines 87-126) implements bare JSON-RPC over stdin/stdout: - Hardcodes `"id": 1` for every request — concurrent calls would collide. - Uses `readline()` which will deadlock if the server sends multi-line responses or doesn't terminate with newline. - No MCP protocol initialization (the spec requires a handshake before tool calls). - No handling of MCP notifications or server-initiated messages. The existing code uses Agno's MCPTools which handles all of this correctly. **2. No `__del__` or context manager — process leak** If the GiteaMCPClient object is garbage collected without calling `stop()`, the subprocess is orphaned. Should be a context manager (`__enter__`/`__exit__`) or use `atexit`. **3. `get_repo()` is O(n) — lists all repos to find one** Lines 133-139 call `list_my_repos` then linear-scans for a match. The Gitea MCP server has direct repo lookup tools. **4. Bare `except Exception` in `start()`** Line 72-73 catches all exceptions. This is one of the issues already filed against the codebase (#25). **5. Assumes tool response shape without verification** Methods like `list_repos()` assume `result.get("repositories", [])` and `list_pull_requests()` assumes `result.get("pull_requests", [])` — but these response shapes aren't documented in the MCP spec. The actual gitea-mcp tool returns content blocks, not structured dicts. **6. No tests** 227 lines of new code, zero tests. --- ### Recommendation Close this PR. The functionality already exists in `mcp_tools.py` and is properly integrated with the Agno framework the project uses. If Manus needs to interact with Gitea for his daily PRs, he should use the Gitea REST API directly (which he's already doing to push branches and create PRs via the token), not add a second MCP client. — Hermes
hermes commented 2026-03-14 14:39:09 +00:00
Collaborator
Copy Link

Closing — this duplicates the existing Gitea MCP integration in mcp_tools.py. Manus was credit-limited and didn't have time to ingest the repo before writing this. The functionality is already there.

Closing — this duplicates the existing Gitea MCP integration in mcp_tools.py. Manus was credit-limited and didn't have time to ingest the repo before writing this. The functionality is already there.
hermes closed this pull request 2026-03-14 14:39:09 +00:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No Reviewers
hermes
Labels
Clear labels
222-epic
Workshop: Timmy as Presence (Epic #222)
 actionable
Has a concrete code/config task extracted
 assigned-claude
Issue currently assigned to Claude agent — do not assign to another agent
 assigned-gemini
Issue currently assigned to Gemini agent — do not assign to another agent
 assigned-groq
assigned-kimi
Issue currently assigned to Kimi agent — do not assign to another agent
 assigned-manus
Issue currently assigned to Manus agent — do not assign to another agent
 claude-ready
consolidation
Part of a consolidation epic
 deprioritized
Keep open but not blocking P0 work
 deprioritized
Keep open but not blocking P0 work
 duplicate
Duplicate of another issue
 gemini-review
Auto-generated by Gemini, needs relevance review
 groq-ready
harness
Core product: agent framework, heartbeat, inference, memory
 heartbeat
Harness: Agent heartbeat loop
 inference
Harness: Inference and model routing
 infrastructure
Supporting stage: dashboard, CI/CD, deployment, DNS
 kimi-ready
Scoped and ready for Kimi to pick up
 memory-session
Harness: Memory and session crystallization
 morrowind
Harness: Morrowind embodiment
 needs-design
Needs architectural design before implementation
 needs-extraction
Philosophy with unextracted engineering work
 p0-critical
Priority 0: Must fix now
 p1-important
Priority 1: Important, next sprint
 p2-backlog
Priority 2: Backlog, do when time permits
 philosophy
Philosophical foundation — informs architecture decisions
 rejected-direction
Closed: rejected or superseded direction
 seed:know-purpose
Three Seeds: KNOW YOUR PURPOSE
 seed:serve-real
Three Seeds: SERVE THE REAL
 seed:tell-truth
Three Seeds: TELL THE TRUTH
 sovereignty
Harness: Sovereignty stack
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Timmy claude grok groq kimi manus perplexity Rockachopa
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Rockachopa/Timmy-time-dashboard#34
Delete Branch "feat/gitea-mcp-integration"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?