Loading ToolBench
Standalone MCP server for credit check tool using Experian API for FICO score assessment in small business loan applications
Single tool 'credit_check' with adequate schema and description, but significant gaps in parameter descriptions, no error handling guidance, missing output documentation in tool definition, and security concerns around SSN handling. The tool definition is visible in src/mcp_credit_server.py with Pydantic models (CreditCheckInput, CreditCheckOutput), but the output schema is not exposed in the MCP tool registration itself, only in Python type hints. Average tool name length (12 chars) is below baseline (18 chars); verb 'credit_check' is somewhat action-like but 'check_credit' would be more conventional. No input validation constraints (SSN format, revenue range) exposed in schema or descriptions.
Securely fetch credit score from Experian API for small business loan applicant. Uses owner's SSN for FICO score (blended for small biz context).
Parameter 'ssn' lacks format/validation constraints and security guidance. Description does not warn about PII sensitivity or mention that SSN is a security-critical input requiring careful handling. No indication that this parameter should never be logged or exposed in traces.
Output schema (credit_score, risk_level, approved_limit, notes) is defined in Python Pydantic models (CreditCheckOutput) but is NOT registered in the MCP tool definition. The @mcp.tool() decorator wraps the function but does not explicitly declare output_schema. LLMs cannot plan downstream operations without knowing the output structure.
Parameter 'business_revenue' has no constraints (min/max). No description of valid range, units (assumed USD), or precision. Unbounded numeric parameters allow LLMs to pass nonsensical values (e.g., negative revenue, 1e100).
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 56 | - | v1 |
No error handling documentation. Code calls get_experian_token() which can fail (network, auth, missing env vars) but tool description does not explain what errors are possible, when to retry, or what to do on permanent failures. No recovery guidance for LLM.
Environment variables (EXPERIAN_USERNAME, EXPERIAN_PASSWORD, EXPERIAN_CLIENT_ID, EXPERIAN_CLIENT_SECRET, EXPERIAN_TOKEN_ENDPOINT) are loaded via dotenv and used directly in get_experian_token(). If logging is verbose, credentials could leak into stderr or logs. No masking or secret redaction observed in logging calls.
Tool description does not specify what risk_level values are possible (e.g., 'low', 'medium', 'high', are there others?). LLMs cannot plan branches on an enum without knowing all valid values. Output schema should enumerate possible risk levels.
No indication of idempotency. Calling credit_check twice with the same SSN and revenue, does it return the same result or make two distinct Experian API calls? If non-idempotent, agents retrying on transient failures will make duplicate calls and charges. Tool description must clarify.
Tool description mentions 'blended for small biz context' but does not explain what 'blended' means or how it differs from standard FICO. This could confuse agents and users about what score they are receiving.