Loading ToolBench
Agentic Portfolio System - A compliance-grade MCP server that serves as both human and machine readable portfolio with agentic AI capabilities
Atlas-G Protocol has fundamental issues across naming, parameter descriptions, and output schemas. While tools are clearly named with action verbs and have non-empty descriptions, the implementation falls short of production standards. Tool descriptions lack depth and guidance for LLM selection. Parameters are present but most lack descriptions or type clarity. Output schemas are not documented anywhere in the visible code. The server exposes authentication tokens as optional parameters, violating security patterns. Tools appear to operate on a single candidate's resume, limiting composition flexibility.
Deep-dive into a specific project's technical architecture. [PROTECTED] Requires auth_token for deep architectural audits.
Check current availability and rate cards.
Get core capabilities (Public).
Get structured professional profile. Returns summary, experience, and skills.
List all sections available (Public).
Query the candidate's resume using semantic search. Publicly accessible for general queries.
Cross-reference employment claims against the verified resume knowledge graph. [PROTECTED] Requires auth_token for detailed verification.
Authentication token exposed as tool parameter. All three protected tools (mcp_verify_employment, mcp_audit_project, and others) accept 'auth_token' as an optional parameter. This violates the secret-injection pattern, credentials in parameters are logged, traced, and appear in prompt history.
Output schemas not documented. No tool in the codebase declares what fields it returns, what types they are, or what structure the response has. LLMs cannot plan downstream calls or extract specific data without knowing the response shape.
Parameter descriptions missing or generic. The 'context' parameter in mcp_query_resume says 'Optional context for the query' but does not explain what format context takes, how it affects results, or when to include it. Parameters like 'inquiry_type' in mcp_check_availability have no description at all in the visible schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Tool descriptions lack context for LLM selection. 'Query the candidate's resume using semantic search' does not explain WHEN to use this vs. mcp_get_professional_profile, what 'semantic search' means in this domain, what query format is expected, or what results look like. Descriptions should be 50-200 chars of guidance.
No error handling guidance. The code defines check_auth() and get_unauthorized_response(), but tools do not document what errors can occur, how they are classified (retryable vs. fatal), or what the LLM should do next. There are no recovery guides.
Ambiguous parameter 'role' in mcp_verify_employment. The description says 'Job role/title' but does not clarify: is this a free-form string, a predefined enum, or a regex pattern? LLMs will guess formats, causing mismatches.
Weak tool naming distinction. mcp_get_professional_profile and mcp_query_resume both retrieve resume/profile data but operate at different abstraction levels. Without clear descriptions, LLMs will conflate them. Consider renaming one to clarify the difference (e.g., mcp_search_resume vs. mcp_get_profile_summary).