Loading ToolBench
Machine Control Protocol (MCP) interface for interacting with the 2GIS Search APIs, providing Places, Geocoder, Suggest, Categories, Regions, and Markers functionality.
The server provides 6 tools for 2GIS search APIs with basic schemas and descriptions. However, there are significant quality gaps: (1) Tool names lack action verbs, 'categories_tool', 'geocoder_tool', 'markers_tool', 'place_tool', 'regions_tool', 'suggest_tool' are all noun-suffixed tool identifiers rather than verb-action names like 'search_categories', 'geocode_address', etc. This violates the core naming pattern and forces LLMs to infer intent. (2) All tool descriptions are present and reasonably detailed (122-194 chars), meeting the 10-1024 char baseline, but lack action-focused context (WHEN to use, dependencies, and what happens). (3) Input schemas ARE documented in the code with types and parameter descriptions, which is good, all tools have well-formed Pydantic models or direct parameter specifications. (4) Output schemas are NOT documented, the code shows API calls to httpx.get() but does not specify what structure is returned. LLMs cannot plan downstream calls without knowing the output shape. (5) Error handling is minimal, HTTPError is caught and logged but not mapped to actionable recovery guidance. (6) Parameter quality is mixed: geocoder_tool has mutually exclusive params (query OR lat/lon) but this dependency is documented in the description. Most other tools have optional location params without clear prioritization. (7) Security: API key is injected via settings (good), but no mention of rate limiting, input sanitization, or permission gates. Overall, the tools are functional but lack the polish and LLM-friendliness of production quality.
The Categories API provides information about categories – groups of companies that share the same business area.
The Geocoder API allows you to determine coordinates and get information about an object on the map by its address (direct geocoding) and vice versa, to determine the address of an object on the map by its coordinates (reverse geocoding).
The Markers API searches for organizations, buildings, and places to display markers on the map. A marker is a representation of an object on the map, so the marker can only be an object with coordinates.
The Places API performs a search for organizations, buildings and places.
The Regions API is used to select a region that limits the searches for organizations, buildings, and places.
Tool names do not start with action verbs. All 6 tools use noun_tool naming (categories_tool, geocoder_tool, etc.) instead of verb_noun (search_categories, geocode_address, etc.). LLMs infer intent from the name first, non-action names force unnecessary parsing and invite wrong tool selection.
Output schemas are not documented. Tools call httpx.get() and return response.json(), but LLMs are not told what fields to expect (e.g., does geocoder return 'items', 'results', 'location'? does markers return 'id', 'name', 'coordinates'?). This forces LLMs to guess field names on downstream operations and breaks composition.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
The Suggest API is intended for providing hints when searching for objects. To get tips, the user just needs to start entering text in the search field. The API will suggest possible objects that match the search criteria. The user will only have to choose from the proposed options. The suggestions take into account the location of the user.
No error recovery guidance. HTTPError is caught and logged, but LLMs receive only the raw exception message. Errors should categorize as retryable (timeout, rate limit) vs user-fixable (invalid query) vs fatal, with actionable next steps.
No result limiting or pagination documented. Tools return raw API responses with no mention of max results, pagination tokens, or size caps. If an API returns 1000 items, LLMs will receive all of them, bloating context and degrading reasoning.
Tool descriptions lack actionable context. While present (65-75 chars), they read like API docs ('The Categories API provides information about categories...') rather than LLM guidance. Missing: WHEN to use each tool relative to others, what prerequisites (query format, location), and example use cases.
Parameter descriptions reference API format but do not enforce it. E.g., 'location in format "latitude,longitude" (optional)' is stated but not validated. If an LLM passes 'Moscow' or '55.7558, 37.6173' (with space), the tool will fail silently or return wrong results.