A multi-tool MCP server with LinkedIn profile scraping and weather forecast capabilities
Three tools with basic verb-noun naming (get_profile, get_alerts, get_forecast). All have descriptions and input schemas with types. However, descriptions are minimal (10-20 chars), parameter descriptions lack detail on format/constraints, and output schemas are undocumented. No error handling guidance, no pagination support despite potential for large results, and no tool annotations. Tools return unstructured JSON strings rather than structured objects. Baseline: 194 chars avg description; these average ~15 chars. No evidence of LLM-optimized descriptions or recovery guidance.
Get weather alerts for a US state.
Get weather forecast for a location.
Get LinkedIn profile data for a given profile URL.
Descriptions are 10-20 characters; rubric requires 10-1024 with 194 char baseline. 'Get LinkedIn profile data for a given profile URL' is minimal and lacks WHEN/WHY context for LLM selection.
Parameter descriptions missing or trivial. 'linkedin_url' has 'The LinkedIn profile URL' (generic); 'state' has 'Two-letter US state code' (no validation hint); latitude/longitude lack range constraints. Rubric baseline: 72 chars avg per param.
Output schemas undocumented. Tools return JSON strings (get_profile returns json.dumps(data)) without declaring structure. LLMs cannot plan downstream calls or extract fields. Rubric: 100% of A+ tools document return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
No error recovery guidance. Exception handlers return bare strings ('Unable to fetch...', 'No alerts found'). Rubric requires: 'Error responses must tell the LLM what to do next.' E.g., 'LinkedIn API timeout. Retry in 30s or check URL format.'
get_alerts and get_forecast may return large result sets without pagination. Rubric: 'cap results at 20-50 and offer pagination.' No limit parameter, no cursor/offset, no total count returned.