Education Data

Several clusters have genuinely unclear boundaries despite verbose descriptions: ask_pipeworx / ask_pipeworx_beta / ask_pipeworx_grounded are near-identical routers (beta is explicitly 'identical' to the stable one), discover_tools overlaps with suggest_questions, and entity_profile / company_facts / compare_entities / recent_changes / validate_claim all answer 'tell me about company X' style queries with different scopes. An agent must read several paragraphs of prose to pick correctly, and for ask_pipeworx vs _beta there is effectively no selection rule at all.

There is a recognizable namespace convention (education_*, polymarket_*, ask_pipeworx*, resolution_*), but the conventions are mixed: some tools are verb_noun (find_districts, validate_claim, generate_llms_txt), some are bare verbs (remember, recall, forget, subscribe), and many are noun_phrases with no action (company_facts, entity_profile, recent_changes, kalshi_weather_edge). It stays readable, but there is no single predictable pattern.

40 tools is heavy for a set that presents itself as a single domain connector, and much of the count comes from parallel/overlapping variants (three ask_pipeworx modes, five Polymarket tools, four subscription/memory CRUD tools). It is a large surface a caller must triage before choosing, though individual tools are nontrivial rather than filler.

If the domain is education, the surface covers district/school directories, district finance, and child poverty, but omits outcome data (assessment/proficiency, graduation rates, enrollment time-series, college scorecard) that an education consumer would expect; if the domain is the broader gateway the server actually exposes, coverage is wide but still missing exposed tools for several data packs it references (e.g. college-scorecard). Memory and subscription lifecycles are complete (create/read/delete), so there are no hard dead ends.