MCP server providing tools for querying Linux Foundation's LFX v2 APIs, including projects, committees, members, meetings, mailing lists, and semantic layer/lens data
Critical assessment: This MCP server has 63 tools but lacks foundational definition quality across the board. Tool descriptions are present in test files but schema definitions are not visible in the provided source code. No input parameter schemas can be verified in main.go or the Dockerfile/Makefile. Tools are registered (names visible in main.go) but without verifiable schemas, parameter descriptions, or output documentation. The server provides READ_ONLY, WRITE, and DESTRUCTIVE tools but offers no error recovery guidance, no confirmation patterns for destructive operations, and no security documentation. Based on the rubric's conservative baseline (most community servers score 40-60; this one is below that due to schema invisibility and lack of parameter documentation), this server scores in the 'poor to failing' range.
No input parameter schemas visible in provided source code. All 63 tools register names and descriptions but input schemas (required for LLM parameter binding) cannot be verified.
Tool descriptions are minimal (30-40 chars on average). Baseline from rubric is 194 chars. Descriptions lack WHEN to use, prerequisites, expected return structure, or error conditions. Examples: 'Get details for a specific LFX project' tells LLM nothing about what fields are returned or when to call search_projects first.
get_project
Recommendations
CRITICAL: Extract and document complete input schemas for all 63 tools. Each schema must include: parameter name, type (string|integer|boolean|object|array), required (boolean), description (min 20 chars), enum (if fixed options), min/max (if numeric), pattern (if regex). Example: { 'committee_id': { 'type': 'string', 'description': 'Unique identifier for the committee. Obtain from search_committees.', 'required': true } }
CRITICAL: Expand tool descriptions to 100-200 characters, following the rubric baseline (194 chars). Template: '[WHAT] This tool [ACTION]. [WHEN] Use it when [SCENARIO]. [RETURN] Returns [FIELDS]. [PREREQUISITES] Requires [ID_TYPE], obtain from [RELATED_TOOL] if needed.' Example: 'Get detailed metadata for a specific LFX project, including members, funding, status, and governance structure. Use after search_projects to fetch full details. Returns project_id, name, description, members_count, status, created_at.'
CRITICAL: Document output schemas for all tools. For each tool, specify the response object structure, field types, and which fields enable chaining to subsequent tools. Example for search_committees: { 'committees': [{ 'id': 'string', 'name': 'string', 'member_count': 'integer', 'created_at': 'ISO 8601 string' }], 'total': 'integer', 'next_cursor': 'string or null' }
Add confirmation pattern for destructive tools (delete_committee, delete_group, delete_member). Implement a confirm_action parameter or split delete into a 'dry_run' response followed by a 'confirm_delete' step. Example: delete_committee should first return what will be deleted, then ask for confirmation before actual deletion.
Score history
Overall score trend
↓ 20 points across a rubric change (v1 → v2)
38/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
38
2026-07-28+
v2
2026-03-09
D
58
-
v1
create_group_memberwriteauthsource verified38/100
Create a new group member (committee mode alternative)
No parameter descriptions visible. LLMs cannot infer parameter meaning from names alone.' Cannot verify that search_* tools document pagination parameters (limit, offset, cursor) or that create_* tools document required vs optional fields.
No output schemas documented. LLMs need to know what fields each tool returns to plan subsequent calls. E.g., does search_committees return committee_id, or just id? Must include_chaining_ids so an agent can pass results to update_committee without extra lookups.
No error recovery guidance. Tools offer no hints for LLM when calls fail. E.g., if get_user returns 404, does the LLM retry with search_users? Or is the user permanently not found? Per pattern:recovery-guide, errors must tell the agent what to do next.
Duplicate tool pairs suggest composition issue. 'committees' vs 'groups' (committee mode alternative), same operations, two names. Violates pattern:tool, 'Avoid multiple tools that do the same thing differently.' LLM wastes reasoning deciding between search_committees vs search_groups.
No pagination guidance visible. search_* tools (search_projects, search_meetings, search_members) lack documented limit/offset/cursor parameters or total count in response. Per pattern:paginated-result, must support pagination to avoid context window exhaustion.
No idempotency guarantees. Tools like create_committee, create_group, send_email can produce duplicate side effects if retried. Per pattern:idempotent-operation, agents retry on ambiguous failures, tools must either be idempotent or document retry behavior.
Tools accept opaque IDs (committee_id, user_id) but no description of how LLMs obtain them. Per pattern:natural-identifiers, tools should accept human-friendly names (email, username) and resolve them internally. Forces LLMs to call search_* first every time.
get_committeeupdate_committeeget_meetingMost get_* and update_* tools
Add permission scopes to tool descriptions. Each WRITE/DESTRUCTIVE tool must declare required scopes. Example: create_committee description should include 'Requires scope: write:committees'. This enables least-privilege agent configuration.
Merge duplicate tools. Consolidate 'committees' and 'groups' into a single canonical pair (or config mode). LLMs should never choose between search_committees and search_groups, only one should exist. Clarify in config/docs which mode is active.
Add error recovery guidance to all tools. When a tool can fail (e.g., user not found, committee not found, rate limited), describe the recovery path in the description. Example: get_committee description: 'If committee_id not found, call search_committees(name=partial_name) to discover the correct ID.'
Implement natural-identifier support. Tools like get_committee(committee_id) should also accept get_committee(committee_name). Add parameter description: 'Either committee_id (UUID) or committee_name (string). If name provided, searches and returns exact match or lists candidates. Prefer ID if available for performance.'
Document idempotency for all create_*/update_* and send_* tools. Add to description: 'Idempotent: calling twice with same parameters returns same result without side effects' OR 'NOT idempotent: repeated calls may create duplicates. Use unique request IDs to prevent.' Example: send_email should support request_id parameter for deduplication.
Add parameter type validation constraints to descriptions. Example: search_committees description should note 'limit must be between 1 and 100; defaults to 20.' Prevents LLM from passing invalid values.
Implement result limits and document them. search_projects should not return 10,000 results. Cap at 50 and note in description: 'Returns up to 50 results per page. Use offset/cursor to paginate.' Per mxe:enforce-result-limits.
Add batch operation variants where agents will loop. For example, assign_discord_role currently takes one user; add assign_discord_roles(users: []) to handle multiple users in one call. Reduces token cost and latency.