Loading ToolBench
Model Context Protocol server that provides tools to query people currently in space and ISS position data
Single tool with minimal definition quality. The tool 'get-people-in-space' has an acceptable name (verb-noun pattern) and a basic description, but critically lacks an input schema definition, parameter documentation, and output schema specification. The description is 104 characters (within baseline range of 34-392) but provides no information about what the tool returns, when to use it, or any prerequisites. The input is declared as an empty object {} with no documented fields or constraints. No output schema is visible in the source code, the tool simply returns a list of TextContent objects with names, but this structure is not formally documented for the LLM. Error handling is absent; there is no guidance for what happens if the API call fails, whether it's retryable, or how the agent should recover.
The list of people in space endpoint returns the list of people in space right now
Input schema is completely missing. Tool declares input as {} with no parameter definitions, types, or descriptions. Per hard scoring rules, schema score must be 0 when no schema is visible.
Output schema is not documented. The tool returns a list of TextContent objects containing astronaut names, but the LLM has no formal specification of the return type, field names, or structure. LLMs cannot plan downstream tool calls or extract data reliably without documented output schemas.
Description lacks WHAT, WHEN, and recovery guidance. The description 'The list of people in space endpoint returns the list of people in space right now' is redundant and tells the LLM nothing about what data fields are returned, when to call this tool vs. alternatives, or what happens on failure. Per pattern:tool-description, descriptions must answer these questions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
No error handling or recovery guidance. The code does not catch or document what happens if peopleInSpaceRepository.fetchPeopleAsFlow() fails. Agents have no guidance on whether to retry, wait, or request alternative data.
No pagination or result limiting. The tool returns all people in space without limit, offset, or pagination parameters. If the result set grows large, it risks exhausting the context window. No limit parameter is documented.
Response structure is undocumented. The code returns people.map { TextContent(it.name) }, which produces TextContent objects. It is unclear what fields are in each object beyond 'name', whether additional metadata (e.g., mission, location, time-in-space) is available, or how the LLM should interpret the response.