Loading ToolBench
MCP server for querying Web3 job listings from the web3.career API with optional filters
The Web3 Jobs Server has one tool (query_jobs) with a clear action verb, comprehensive parameter descriptions, and explicit input schema. However, there are significant gaps in output schema documentation, error handling guidance, and tool composition patterns. The tool description is adequate (194 chars) and exceeds the 10-char minimum, but lacks explicit guidance on when/why to use it vs alternatives. Parameter validation is present (limit bounds checking) but error messages are generic. The tool returns Markdown strings rather than structured JSON, which requires LLM post-processing. No pagination support despite the API accepting a limit parameter, and no documented output schema structure.
Query Web3 job listings from the web3.career API with optional filters. Returns a Markdown-formatted list of jobs, including Job ID, Title, Company, Location, Remote status, Published At date, Apply URL, and Description (always included).
Output schema not documented. Tool returns unstructured Markdown string instead of typed JSON object with fields (job_id, title, company, location, remote, published_at, apply_url). LLMs must parse free-text output, increasing token cost and error likelihood.
Error handling provides no recovery guidance. ValueError raised for limit>100 or API failures returns raw exception text. Should classify errors as retryable vs user-fixable and offer actionable next steps (e.g., 'Limit must be 1-100. Try search_jobs() with limit=50').
No pagination or result limiting stated in description. Tool accepts limit parameter but description does not explicitly state it caps at 100 or warn about context window impact. Large result sets (200+ jobs) will bloat responses and degrade LLM reasoning.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Tool description lacks WHEN/WHY guidance. Does not explain when to call query_jobs vs other discovery tools, or what makes a result good/bad. LLM must infer intent from context alone.
Parameter 'remote' accepts None/True/False but description text says 'Set to True for remote-only, False for non-remote, or None for no filter', unclear whether None is required to omit filter or just one of several options. Should use Optional[bool] type hint with clearer semantics.
Description includes implementation detail: 'Descriptions are always included (show_description is hardcoded to True), truncated to 100 characters'. This leaks internal logic; users don't care about truncation policy. Should state: 'Descriptions (max 100 chars, HTML stripped) are always included'.