ag2 exposes 2 tools via HTTP MCP. Both tools lack critical definition quality. tool_search has a generic, unhelpful description ('Server-side tool search over a set of deferred tools') that does not explain what a 'deferred tool' is, when to use this vs alternatives, or what it returns. run_code has a better description template but relies on string interpolation ({languages}) that is not visible in the static source, making the actual constraint unknown. Neither tool has a visible input schema in the provided source, only run_code shows a partial schema hint in the metadata (code: string, language: string), but there is no evidence of enum constraints on 'language', parameter min/max bounds, or output schema documentation. tool_search has no visible parameter definitions at all. Error handling is not documented for either tool. The codebase appears to be a framework (ag2) rather than a standalone MCP server implementation, so tool definitions may be dynamically constructed or delegated to client code, which prevents full static analysis. This is a major blocker, if tool registration happens at runtime or via configuration not visible in the source files provided, the tools cannot be properly evaluated.

• Add explicit input JSON Schema to tool_search with all parameters, types, and descriptions. Define what 'deferred tools' are (e.g., tools not yet registered with MCP, dynamically loaded from a registry?).
• Rewrite tool_search description as: 'Search for tools in the deferred tool registry. Returns matching tool names, descriptions, and signatures. Use this to discover custom tools registered at runtime before calling them. Returns list of {name, description, input_schema}.'
• Resolve {languages} placeholder in run_code description. Explicitly list all supported languages: 'Supported languages: python, javascript, bash, java, csharp, go, rust, cpp. Language must match one of these values exactly.'
• Add enum constraint to run_code 'language' parameter with explicit list: ["python", "javascript", "bash", "java", "csharp", "go", "rust", "cpp"].
• Document run_code output schema: {stdout: string, stderr: string, exit_code: integer, execution_time_ms: integer, status: 'success'|'timeout'|'error'}.
• Add clear error handling guidance to run_code: 'On syntax error, returns exit_code non-zero with stderr. On timeout (>30s), returns status=timeout. Execution is NOT retryable if it has side effects (file writes, API calls).'
• Bound run_code 'code' parameter: 'Max 10,000 characters. Execution timeout: 30 seconds. Memory limit: 512 MB. No network access. No file I/O outside /tmp.'
• Implement confirmation pattern for run_code: add optional 'dry_run: boolean' parameter (default false). When true, validates syntax and returns what would execute without actually running it.

Inferred effective spec: 2026-07-28+.

• Current-spec patterns present: stateless request handling, Multi Round-Trip Requests, structured tool output, tool annotations, Streamable HTTP