Loading ToolBench
A Streamlit application that answers movie-related questions by combining vector-based semantic search on a Chroma vector database with dynamic tool invocation via MCP (Model Context Protocol). Uses LangChain and OpenAI LLM to decide whether to answer directly or call backend MCP tools to fetch additional movie data.
This MCP server exposes only one tool (getObjectModelSummary) with an empty input schema and a generic, uninformative description. The tool definition is inferred from code rather than explicitly registered with proper MCP patterns. The server lacks input validation, error handling guidance, security controls, and composition patterns. It does not follow the 54 Agentic Tool Patterns baseline and falls well below production quality standards.
Retrieves a summary of the object model available in the backend MCP server
Tool has an empty input schema ({}). No parameters are defined, documented, or typed. This violates the critical schema requirement that every tool must have a properly formatted JSON Schema with typed fields.
Tool description is generic and uninformative (only ~70 chars: 'Retrieves a summary of the object model schema used by the Gilhari microservice for movie objects'). Lacks context on WHEN to call it, WHAT it returns, and WHY it matters for the agent's planning. Descriptions must be 10-1024 chars and explicitly guide LLM tool selection.
Tool name 'getObjectModelSummary' does not follow clear verb_noun convention. Unclear what 'ObjectModel' means in the movie domain. A verb like 'get_' is present, but the noun is jargon-heavy ('ObjectModel' vs 'movie_schema' or 'movie_fields'). LLMs struggle to infer intent from vague nouns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 9 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 19 | - | v1 |
No output schema documented. The tool's response format is unknown, does it return JSON, a string, an object? LLMs cannot plan downstream calls without knowing what fields to expect. The code shows it returns tool_result with tool_result.content[0].text, but this is not documented in the tool definition.
No error handling or recovery guidance. The code calls session.call_tool() with no try-catch around the tool invocation itself. If the tool fails, there is no error message telling the LLM what to do next (retry, call a different tool, ask the user). Errors should be categorized as retryable, user-fixable, or fatal.
Hardcoded API credentials in source code. The file contains 'api_key = "helllo"' and 'api_key="t33IIC5s6C2Zn4hDgBzNjh2TYhNHDB8Y3bfdtzs1"' in plaintext. Secrets must never appear in tool parameters or source code, use environment variables or vault injection. This is a critical security vulnerability.
Tool does not declare required permissions or scopes (e.g., 'read:movie-schema'). No audit trail visible for who called the tool, when, or with what outcome. Production tools must log invocations for compliance and debugging.
Tool is registered implicitly in Streamlit app code (streamlit_app.py) rather than in a proper MCP tool registry. No explicit MCP ToolDefinition or schema registration visible. Tool existence is inferred from the call 'await session.call_tool("getObjectModelSummary", {})', this violates explicit registration requirements.