Grab and deploy Haystack pipelines with MCP server support for tool exposure
Hayhooks exposes two example tools from demo pipelines with minimal schema documentation. Both tools have descriptions and basic parameter definitions, but schema completeness is limited. The tool definitions appear to be inferred from example files rather than formally registered with full MCP server infrastructure. Input schemas are present but lack proper type declarations and comprehensive parameter descriptions. No documented output schemas. No error handling guidance. No tool annotations.
Get current weather for a city. Returns temperature, humidity, wind speed, and conditions.
Suggest activities for a city given the current weather conditions.
Tool definitions appear to be inferred from example files, not formally registered in MCP server code. No evidence of explicit tool registration with full schema details in the main hayhooks codebase.
No documented output/response schemas. Clients cannot predict what fields these tools return, forcing agents to guess at response structure and breaking tool chaining.
Input parameters lack JSON Schema type declarations. While 'city' and 'location' are named reasonably, the schema definitions do not show explicit 'type': 'string' declarations required by the MCP spec.
No pagination or result limits documented. If suggest_activities or get_weather return multiple items, there is no indication of limits or pagination support, risking context window overflow.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Tool descriptions are generic and lack LLM-optimized detail. 'Suggest activities for a city given the current weather conditions' (68 chars) and 'Get current weather for a city...' (158 chars) are present but do not answer WHEN to use each tool, what specific fields are returned, or how they relate to each other.
No error handling guidance. Descriptions do not explain what happens if a city is not found, if weather service is unavailable, or what the agent should do on failure.
Parameter descriptions are minimal. 'City name, e.g. Berlin' (21 chars) and 'Short weather description, e.g. Light rain or Clear sky' (54 chars) include examples that LLMs may reuse literally rather than adapt to context. Prefer formal enum/pattern constraints.