Repository navigation
[mcp-analysis] MCP Structural Analysis - 2026-10-20 #70515
Closed
Replies: 1 comment
|
This discussion has been marked as outdated by GitHub MCP Structural Analysis. A newer discussion is available at Discussion #70877. |
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.
Overview
Tested 10 representative GitHub MCP tools/toolsets with minimal parameters (
perPage: 1or single-item queries) and recorded size, schema, and agentic usefulness. Today's run used 3,930 tokens across the sample, with an average usefulness rating of 3.40/5 — the highest of the 7 sampled days in the 30-day window (2026-10-12 to 2026-10-20, 73 data points).The standout finding:
search_issuesreturned a real, unfiltered closed issue with a full markdown body for the first time in 3 sampled days (prior days hit integrity-policy filtering), lifting its rating from 1-2 to 4/5. Meanwhilelist_issues,list_code_scanning_alerts, andlist_discussionscontinue a now 6-day streak of single-item empty-array responses due to integrity/secrecy policy filtering — a structural limitation, not a transient blip.Key Metrics
github_context,list_pull_requests,list_workflows(5/5 each)list_issues,list_code_scanning_alerts,list_discussions,search_users(2/5 each)Full Structural Analysis Report
Usefulness Ratings for Agentic Work
Schema Analysis
Response Size Analysis (30-day average by toolset)
Note:
reposaverage is inflated by a one-off 26,901-token oversized-README failure on 2026-10-19; excluding that outlier the toolset averages ~1,400 tokens (consistent with the LICENSE-file baseline).Tool-by-Tool Analysis (Today)
30-Day Trend Summary
Visualizations
Response Size by Toolset
Usefulness Ratings
Daily Token Trend
Size vs Usefulness
Recommendations
github_context(free),list_pull_requests/list_workflowswith explicitfields/mcpscripts wrappers,get_label, andsearch_issueswhen results clear integrity filtering.list_issues,list_code_scanning_alerts,list_discussionsare now structurally gated by integrity/secrecy policy on single-item exploratory queries in this repo — 6 consecutive sampled days of empty-array false negatives. Agents relying on these for triage should treat an empty array as "possibly filtered," not "confirmed empty."search_usershas no low-overhead substitute since noget_usertool exists.github_context(58 tok),list_pull_requests(40 tok),list_workflowsvia mcpscripts (172 tok) — all consistently ⭐⭐⭐⭐⭐ across the 7-day sample.get_file_contents/repos (1,380 tok baseline, worse if the large-file guard isn't applied first),search_users/get_labelbuilt-in calls (both >600 tok due to fixed ~2.4KB icon/_meta wrapper overhead that the mcpscripts wrappers avoid entirely).All reactions