Loading ToolBench
SushiMCP a dev tools model context protocol server that serves context on a roll.
SushiMCP has 7 tools with mixed quality. The documentation/fetching tools (list_llms_txt_sources, fetch_llms_txt, list_openapi_spec_sources, fetch_openapi_spec) have reasonable descriptions and proper schemas with URL validation. However, GitHub tools (github_issues, github_pull_requests, github_projects) have overly complex schemas with many optional conditional parameters and descriptions that don't clearly state prerequisites or error recovery paths. Tool names follow verb_noun conventions well. Parameter descriptions exist but lack clarity on constraints, ranges, and mutual exclusivity. No output schemas are documented. Error handling is not visible in the code sample provided. Overall definitions are competent but lack the LLM-optimization and completeness expected of production-grade agent tools.
Fetches the content of one or more llms.txt URLs. Some llms.txt files compile a list of urls to other llms.txt file locations because listing their full documentation would bloat context. If the documentation you're looking for does not exist in the llms.txt, look for reference links to other llms.txt files and follow those.
Fetches the content of one or more OpenAPI spec URLs.
Manages GitHub Issues for tracking bugs, features, and tasks. Supports listing issues with filters, getting issue details, creating new issues, updating existing issues, closing issues, and adding issues to GitHub Projects.
Manages GitHub Project items for planning and tracking work. Supports listing, getting, creating, updating, and deleting project items within a GitHub ProjectV2 board. Use this to create and manage tasks, update statuses, and track progress.
Manages GitHub Pull Requests for authoring, reviewing, and iterating on code changes. Supports creating PRs, listing open PRs, reading PR details, reading and posting comments (general and inline), requesting reviewers, merging, and closing PRs.
GitHub tools have overly complex schemas with many conditional optional parameters (fieldId vs status, iterationId vs iteration, etc.) that lack explicit documentation of mutual exclusivity. Parameters like 'status', 'iteration', and 'priority' claim to 'auto-discover field ID' but this implementation detail is not explained or validated in descriptions.
No output schemas documented for any tool. Tool descriptions state what the tools do but do not specify the structure of returned data. LLMs cannot plan downstream calls or extract chaining IDs without knowing response fields. fetch_llms_txt and fetch_openapi_spec likely return the file content as text, but structure is undocumented.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 28 | - | v1 |
This tool lists all available source urls where an llms.txt can be fetched. After reading the listed sources, use fetch_llms_txt to fetch any source that matches a technology in the instructions you received. Prefer llms.txt, but if llms.txt proves inadequate, check to see if other llms-full.txt or llms-mini.txt exist. When done, ask the user if they want to use other tools to search for documentation on any sources this tool could not find.
This tool lists all available source urls where an OpenAPI spec can be fetched.
GitHub tools lack clarity on required parameter dependencies. The github_issues 'add_to_project' action requires projectNumber and issueNumber, but the description does not explicitly state this. Similarly, github_pull_requests 'create' requires 'head' and 'base' but descriptions are vague about prerequisites.
Descriptions for fetch_openapi_spec and list_openapi_spec_sources are under 100 characters and lack detail on use cases, limitations, or when to prefer one source over another.
github_pull_requests and github_issues parameters like 'base', 'mergeMethod', 'owner' claim to be 'already configured via environment' but descriptions do not explain what happens if the user explicitly provides a value. This ambiguity could confuse LLMs about whether to include optional overrides.
No evidence of error handling guidance in tool descriptions. None of the 7 tools explain what to do if a URL fetch fails, a GitHub API call returns 404, or permissions are insufficient. Per pattern:recovery-guide, error responses should guide the LLM on next steps (retry, lookup, ask user).
github_projects, github_pull_requests, and github_issues accept a 'owner' parameter claiming it is 'already configured via environment. Only provide if the user explicitly specifies a different owner.' This is confusing because the schema does not indicate a default value, and LLMs may not understand when to omit it.