Loading ToolBench
OAgent is a desktop Electron application, not an MCP server. It appears to be a client that consumes MCP tools and displays results, rather than exposing an MCP interface itself. Package.json lists @modelcontextprotocol/sdk as a dependency, but source code analysis reveals: (1) Tool definitions are inferred from React component renderers (McpToolContent.tsx) rather than explicit MCP tool registration. (2) No input schemas are visible in the codebase, only tool names and basic descriptions extracted from comments/component structure. (3) Tools like 'Bash' (destructive), 'Write', 'Edit' lack any documented safety constraints or error guidance. (4) Parameter descriptions are minimal or absent, 'command' in Bash has minimal guidance on what constitutes a valid/safe command. (5) No evidence of output schema documentation, pagination support, or result limits. (6) This is a CLIENT application rendering tool results, not a SERVER exposing tools via MCP protocol. The evaluation treats the visible tool definitions as if they were an MCP server, but they fall far short of production quality.
Execute bash commands
Edit file contents
Find files matching glob patterns
Search file contents with regex
Read file contents
Execute background tasks
Update task list items
Fetch web page contents
Search the web
No explicit MCP tool registration visible. Tool definitions are inferred from React component code and function names, not from a formal MCP server toolset declaration. Per HARD SCORING RULE, tools defined this way cannot exceed 50 points each.
Input schemas are not visible for most tools (30/30). Tools with visible schemas (searchJiraIssuesUsingJql, getJiraIssue, getVisibleJiraProjects, searchConfluenceUsingCql, resolve-library-id, query-docs, search, fetch) show only parameter names and minimal descriptions, no type definitions, enums, ranges, or constraints are documented. Per HARD SCORING RULE, schema score MUST be 0 if no schema is visible.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 33 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Write content to files
Add a comment to a Jira issue
Get Atlassian user information
Create a new Confluence page
Create a new Jira issue
Edit an existing Jira issue
Rovo Fetch - fetch Atlassian resource
Get accessible Atlassian resources
Get a Confluence page
Get Confluence spaces
Get a single Jira issue by ID or key
Get available status transitions for a Jira issue
Get visible Jira projects, optionally filtered by search string
Look up a Jira user account ID
Context7 - query documentation
Context7 - resolve library ID
Rovo Search - search Atlassian resources
Search Confluence using CQL query
Search Jira issues using JQL query
Transition a Jira issue to a new status
Update an existing Confluence page
Descriptions are missing or under 20 characters for most tools (23/30). Critical write/destructive tools like 'Bash' (described only as 'Execute bash commands'), 'Write', 'Edit', and 'Task' have no guidance on safety, required permissions, side effects, or recovery options. Per HARD SCORING RULE, description score CANNOT exceed 40 if under 20 chars; MUST be 0 if missing.
No evidence of error handling or recovery guidance. Tools that fail (network errors, permission denied, resource not found) have no guidance on what the LLM should do next. Destructive tools (Bash, Write, Delete) have no dry-run or confirmation pattern. Per pattern:recovery-guide, every tool should guide the LLM on recovery steps.
Generic or single-character tool names reduce clarity. 'Bash', 'Read', 'Write', 'Edit', 'Grep', 'Glob', 'Task', 'search', 'fetch' are generic and lack action-verb specificity. Per naming baselines, 90% of A+ tools start with clear action verbs like get_, create_, search_. Generic names force LLMs to infer intent and disambiguate tools.
No documented output schemas. Tools return results (e.g., JiraIssueList, ConfluenceSearchResults, RovoFetchResult) but the source code only shows React rendering logic, not the actual schema or field documentation. LLMs cannot infer downstream chaining IDs (issue_id, channel_id) or understand result structure.
Write and destructive tools (Bash, Write, Edit, Delete file ops, all Jira/Confluence mutators) lack permission gates, audit logging, or dry-run confirmation patterns. Per pattern:permission-gate and pattern:confirmation-request, destructive operations must verify authority and offer confirmation before executing.
No pagination or result limits documented. Tools like searchJiraIssuesUsingJql and searchConfluenceUsingCql may return large result sets but have no limit param, no offset/page param, and no guidance on result truncation. Per pattern:paginated-result, tools returning lists must support pagination.
Parameter descriptions are missing or trivial for all tools with visible schemas. Only tool names and parameter names are provided, no guidance on valid values, enums, ranges, required format, or dependencies. E.g., 'jql' param has description 'JQL query string for searching Jira issues' but no guidance on JQL syntax or examples of valid queries.
This is a desktop Electron client application, not an MCP server. It consumes MCP tools and renders results in a UI. There is no evidence of an MCP server endpoint, HTTP/SSE transport layer, or tool registry exposed via the MCP protocol. Evaluating as a client rather than a server.