[mcp-analysis] MCP Structural Analysis - 2026-04-14 #26210
Closed
Replies: 1 comment
-
|
This discussion has been marked as outdated by GitHub MCP Structural Analysis. A newer discussion is available at Discussion #26420. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
9 GitHub MCP tools analyzed across 6 days of historical data (Mar 30 – Apr 14). New finding today: 4 tools hit the installation rate limit (15,000 req/reset), the first rate-limit event in this series. Tools that did respond show consistent patterns:
search_repositoriesandget_file_contentsremain top-rated (5/5),list_discussionsis the most token-efficient (155 tokens, 4/5), andlist_code_scanning_alertscontinues to be the most problematic (no pagination, historically dumps 138K+ chars).Today's metrics: 9 tools tested · 4,630 total tokens · 3.44 avg rating · Rate-limit affected: 4 tools
Full Structural Analysis Report
Executive Summary
get_file_contents/search_repositories: 5/5get_me: 1/5 (persistent 403)list_pull_requests,list_workflows,get_file_contents,list_code_scanning_alerts)Usefulness Ratings for Agentic Work
get_file_contentssearch_repositorieslist_issueslist_pull_requestslist_discussionslist_workflowsper_pageparam ignored; 5 URL fields per entry adds unnecessary bloatlist_labellist_code_scanning_alertsget_meSchema Analysis
get_meget_file_contentslist_issueslist_pull_requestslist_workflowslist_discussionslist_code_scanning_alertslist_labelsearch_repositoriesminimal_output=truedefault is excellentResponse Size Analysis (Successful Responses Only)
per_pageignored; always returns 30 entriesminimal_output=trueworks wellTool-by-Tool Analysis (Today: 2026-04-14)
get_melist_issueslist_pull_requestslist_workflowsget_file_contentslist_discussionslist_code_scanning_alertslist_labelsearch_repositoriesNotable Trend: Rate Limiting (New Finding)
First occurrence of installation rate limiting observed today (Apr 14). The GitHub API rate limit of 15,000 req/installation reset at 12:26 UTC. Four tools were affected when called after
list_issues(which has a large body). This suggests that:list_code_scanning_alertsresponse (137K chars) is particularly costly per call30-Day Trend Summary
Recommendations
High-value tools (4–5⭐) — use freely:
search_repositories: Best context efficiency for discoverylist_discussions: Most stable and compact; ideal for pollingget_file_contents: Direct content with SHA caching supportlist_issues/list_pull_requests: Good data but budget for body variabilityTools needing care (3⭐):
list_workflows: Request pagination support forper_page; eliminate 3 of 5 URL fieldslist_label: Add pagination support; 464+ entries is heavy for large reposAvoid or use with caution (1–2⭐):
list_code_scanning_alerts: Implementper_pagepagination urgently; current behavior can consume entire context window in one callget_me: Structural 403 — integration needs user-level OAuth scope to be usefulRate limit awareness:
Visualizations
Response Size by Toolset
Usefulness Ratings by Toolset
Daily Token Usage Trend
Token Size vs Usefulness
References:
Beta Was this translation helpful? Give feedback.
All reactions