Loading ToolBench
Local Context Instructions Server - provides context-aware instructions for working with third-party packages and dependencies across multiple programming languages
This MCP server has two tools with significant quality gaps. Both tools are explicitly registered in internal/server/server.go with descriptions and input schemas visible. However, the descriptions are problematic: they are excessively long (>1000 chars each), use aggressive all-caps language ('CRITICAL', 'MANDATORY', 'DO NOT'), and read like jailbreak prompts rather than professional tool documentation. The tool names are acceptable (verb_noun format), but schema quality is poor. Tool 1 (list_supported_languages) has an empty input object with no parameters, this is valid but minimal. Tool 2 (get_context_instructions) has one parameter 'language' with a type string and a description buried in a struct tag. Critical issue: neither tool's output schema is documented in the MCP Tool definition, output is inferred from the handler return types but not formally declared to clients. This violates the pattern:tool requirement that output schemas be documented. The server offers only prompts and tools, no resources, logging, cancellation, progress, or error reporting features. Error handling is minimal, the server returns plain text error messages in CallToolResult.Content rather than structured error objects with recovery guidance.
MANDATORY when working with ANY third-party package, library, dependency, or external module. This tool provides authoritative, systematic instructions for correctly understanding and working with code in a specific language ecosystem. These instructions are CRITICAL because: 1) They show you how to locate and inspect the ACTUAL source code in local caches (not outdated online docs), 2) They provide proven methods for understanding package structures, module systems, and dependency resolution, 3) They prevent common mistakes and incorrect assumptions that lead to bugs. BEFORE calling: Use list_supported_languages first to verify support. WHEN to use: IMMEDIATELY when you see imports, require statements, package declarations, or any reference to external code. These instructions are your source of truth - ignore them at your peril. They are specifically designed to help you work with real, local codebases rather than relying on potentially outdated or incomplete documentation.
CRITICAL: You MUST call this tool FIRST whenever you encounter third-party packages, libraries, dependencies, or external modules in ANY codebase. This tool reveals which programming languages have proven, battle-tested context instructions available. These instructions are ESSENTIAL for working correctly with dependencies - they prevent you from making incorrect assumptions, using outdated documentation, or misunderstanding package structures. Workflow: 1) Call this tool first to see available languages, 2) Then immediately call get_context_instructions with the relevant language. DO NOT attempt to work with third-party code without first checking and applying these context instructions - doing so leads to errors, incorrect implementations, and wasted time.
Tool descriptions are excessively long (>1000 chars each) and use aggressive all-caps language ('CRITICAL', 'MANDATORY', 'DO NOT') that reads like a jailbreak prompt, not professional documentation. Descriptions should be 10-200 chars per pattern:tool-description. LLMs do not need to be yelled at; they need clear, concise action guidance.
Output schemas are not documented in the MCP Tool definitions. Handlers return structured data (getSupportedLanguagesOutput, etc.), but the Tool schema field is not populated. LLMs cannot infer downstream field names or types. Per pattern:tool, output schemas must be formally declared.
Error handling returns unstructured text in CallToolResult.Content. No error classification (retryable vs user-fixable vs fatal), no recovery guidance. Per pattern:recovery-guide, errors should tell the agent what to do next. E.g. 'No context instructions found for language: X. Available languages: [...]' is helpful, but returns nil for structured output, forcing the agent to parse text.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 38 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Parameter 'language' in get_context_instructions has a description only in the struct tag comment, not in the MCP schema. The struct comment 'Language is the programming language...' is readable to humans reviewing code, but LLMs never see it. The MCP ParameterDefinition must include a description field. Currently hidden from clients.
Tool 1 (list_supported_languages) has an empty input schema (struct{}{}) with no parameters. While technically valid for a zero-argument tool, it lacks documentation about when to call it and why it's a prerequisite. Description text addresses this, but a well-designed discovery tool should have a companion note in its output suggesting the next action.