Loading ToolBench
Integrates Lineai's powerful codebase knowledge graphs with a Model Context Protocol (MCP) server
The server provides 8 tools for Lineai codebase knowledge graph analysis. Tool names follow verb_noun convention (lineai-graph-search, lineai-database-impact) which is appropriate. However, there are significant gaps: (1) Parameter descriptions are minimal or missing for most tools, parameters like 'scan_space', 'materialized_view_id', 'prefer_latest_scan' lack descriptions explaining what they control or when to use them. (2) Output schemas are completely undocumented, no tool declares what fields the response contains, what structure LLMs should expect, or how to chain results into downstream calls. (3) Tool descriptions are lengthy (200-300+ chars) and focus on workflow recommendations rather than concise WHAT/WHEN/WHY statements. (4) No error handling guidance, tools return JSON responses on success but no documentation of failure modes, retry eligibility, or recovery steps. (5) Responses are raw JSON payloads with no indication of field structure or semantic meaning. (6) No pagination mechanism documented despite tools accepting 'limit' parameters. (7) Security and permissions are not addressed, no indication of what scopes/permissions each tool requires.
Analyze impacts between code and database entities. Uses LINEAI_WORKSPACE_NAME environment variable to determine the target workspace. Recommended workflow: 1. Use this tool before implementing code or database changes 2. Search for the relevant database entity 3. Review the impact analysis to understand which code depends on this database object and vice versa Particularly crucial when AI-suggested modifications are being considered or when modifying SQL code.
Fetch graph API capabilities/manifest from the Lineai server (GET). Returns label and relationship metadata when the graph tier is deployed; otherwise explains missing routes. Uses LINEAI_WORKSPACE_NAME for MV id unless `materialized_view_id` is set.
Bounded graph impact from seed node ids (curated HTTP API). Optional `direction` (upstream|downstream|both), `depth`, `scan_space`, `materialized_view_id`.
Look up owners/reviewers for a graph node (curated HTTP API). Provide `node_id` or `identity_prefix`.
Explain bounded paths between two graph nodes (curated HTTP API). Requires `from_node_id`, `to_node_id`; optional `max_depth`, `scan_space`, `materialized_view_id`.
Parameter descriptions missing or incomplete for most parameters. 'scan_space', 'materialized_view_id', 'prefer_latest_scan', 'limit', 'direction', 'depth', 'max_depth' have no descriptions in the schema. LLMs cannot infer parameter meaning without explicit descriptions.
No output schema documented for any tool. LLMs do not know what fields to expect in responses, making it impossible to plan downstream tool calls or extract specific data. All tools return raw JSON via markdown_json wrapper.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Search the Lineai knowledge graph (curated HTTP API). Provide `query` or `identity_prefix`; optional `scan_space`, `materialized_view_id`, `limit`. Requires server route POST .../ai-retrieval/graph/search.
Validate whether a proposed change scope is safe given seed graph nodes (curated HTTP API).
Analyze impacts of modifying a specific method within a given class or type. Uses LINEAI_WORKSPACE_NAME environment variable to determine the target workspace. Recommended workflow: 1. Use this tool before implementing code changes 2. Run the tool against methods or functions that are being modified 3. Carefully review the impact analysis results to understand potential downstream effects Particularly crucial when AI-suggested modifications are being considered.
No error handling guidance. Tools return TextContent with error messages but there is no documentation of error categories, retry eligibility, or recovery steps. A graph_error_message() function is called but its output format and guidance are not documented.
Tool descriptions are verbose (200+ chars) and emphasize workflow recommendations over concise WHAT/WHEN clarifications. Descriptions should be 10-200 chars and answer: What does it do? When should the LLM call it? What does it return?
Undocumented parameter relationships and defaults. Parameters like 'materialized_view_id' have smart defaults (derived from workspace name via get_mv_id) but this is not documented in the parameter schema. LLMs cannot rely on defaults they don't know about.
No documentation of permission requirements or scope declarations. Tools call external HTTP APIs (lineai-graph-*) but there is no indication of what scopes, API keys, or permissions are required.
No pagination documentation. Tools accept 'limit' parameters and the lineai-graph-search handler has comments about 'server may cap', but there is no documentation of pagination mechanism (cursor, offset, total count) or result limits in the tool description.
Parameter enum values not fully specified. 'direction' enum is ['upstream', 'downstream', 'both'] but other parameters like 'entity_type' (column|table|view) and 'scan_space' lack enum definitions in the schema shown, limiting LLM validation.