OpenL MCP Server

Official

by openl-tablets

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.0
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., list vs. create vs. delete). However, the large number of fine-grained table editing tools (append, insert, update, etc. with row/column/cell variants) can cause confusion despite detailed descriptions.
Naming Consistency5/5
All tools follow a consistent 'openl_verb_noun' pattern (e.g., openl_append_table, openl_create_project). There is no mixing of conventions; snake_case is used uniformly.
Tool Count2/5
With 56 tools, the set is excessively large for typical MCP servers. While the domain is complex, many table editing tools could be merged (e.g., append/update/delete rows/columns as parameters). This high count reduces coherence.
Completeness4/5
The tool set covers the full lifecycle: project management, table CRUD, file operations, tests, tracing, deployment, and branching. Only minor gaps exist (e.g., no direct rename table tool, but update_table covers it).
Average 4.3/5 across 56 of 56 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 103 commits in the last 12 weeks
- Last stable release on July 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under LGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only an openWorldHint annotation (not behavior-related), the description carries the burden of behavioral disclosure. It merely states the action without explaining effects on trace data, confirmation requirements, or whether cancellation is reversible, which is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous information. Every word is necessary, achieving ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters with full schema coverage and no output schema, the description is minimally adequate. However, it lacks any mention of return values or confirmation behavior, which would improve completeness for a simple cancellation action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no new meaning beyond the schema, achieving the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Cancel' and specific resource 'ongoing trace execution for a project', which effectively conveys the tool's purpose. However, it does not explicitly differentiate from sibling tools like openl_start_trace or openl_export_trace, though the name itself is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. This leaves the agent without context for appropriate selection among trace-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and open world. Description does not add behavioral context such as whether previous deployments are overwritten, permission requirements, or what happens on success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by a key usage note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Does not describe return value, deployment lifecycle, or how to verify success. For a production deployment tool, more context (e.g., 'Returns deployment ID') is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage). Description reinforces one point about repository naming but adds no substantial new meaning beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Deploy', resource 'a project', and target 'production environment'. However, it does not differentiate from sibling tool 'openl_redeploy_project', which is a closely related action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific guidance on using repository name instead of ID, but does not explain when to use this tool over alternatives like openl_redeploy_project, or mention prerequisites like project being open.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint as true, so the safety profile is clear. The description adds that it returns full project structure, configuration, and status, but does not elaborate on potential side effects, authorization needs, or rate limits. The description adds moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the tool's purpose and scope. It is front-loaded and without unnecessary words, though it could be slightly more specific about what 'comprehensive' means.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should provide sufficient information about the return value. It mentions modules, dependencies, metadata, structure, configuration, and status, which is adequate but somewhat vague. More specific details about the structure or typical fields would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for both 'projectId' (exact value from openl_list_projects) and 'response_format' (enum with defaults). The description does not add additional semantic meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves comprehensive project information including details, modules, dependencies, and metadata. It uses a specific verb ('Get') and resource ('project information'), and distinguishes from sibling tools like openl_project_status or openl_get_project_agent_context by emphasizing the comprehensive nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor does it reference sibling tools like openl_list_projects or openl_get_table for other types of project data retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and open-world behavior. The description adds that it returns repository details but does not elaborate on pagination or other behavioral aspects beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with three short sentences that directly state the purpose and return values. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with good annotations, the description covers the core purpose, return content, and usage context. However, it lacks mention of pagination via limit/offset and fails to distinguish from the similar sibling 'openl_list_repositories'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 33%, yet the description does not mention any parameters. Only 'response_format' has a schema description, but the tool's description adds no parameter guidance, leaving limit and offset undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists deployment repositories and returns names, types, and status. However, it does not explicitly differentiate from the sibling tool 'openl_list_repositories', which might cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests using this tool before deploying projects, providing a usage context. However, it does not specify when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide openWorldHint and idempotentHint, lowering the bar. The description adds that it updates or rolls back a deployment, but does not disclose side effects like whether the old version is preserved or replaced. Adequate given annotations, but could be richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no extraneous words. Efficiently conveys the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description omits what the tool returns or any post-redeployment state. For a redeploy action, users might need to know if the previous deployment is replaced or kept. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes parameters thoroughly. The description does not add new meaning to the parameters, aligning with baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool redeploys an existing deployment with a new project version, including rollback. It implicitly distinguishes from 'openl_deploy_project' (likely initial deployment) through the prefix 'redeploy', but does not explicitly differentiate among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (update or rollback) but does not provide explicit when-not scenarios or alternatives. Given the sibling set includes 'openl_deploy_project', guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint, so safety is clear. The description adds behavioral details about the returned data (id and name) and a warning about value authenticity, which is helpful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, and each sentence adds value. However, it could be slightly more concise by merging the second and third sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description explains return fields and usage in other tools. However, it omits information about pagination (limit/offset behavior) and the response_format parameter, which are present in the schema but not described, leaving completeness gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the three parameters (limit, offset, response_format) beyond what is in the input schema. With 33% schema coverage, the description should compensate but fails to add semantic value for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all design repositories and specifies the returned fields (id, name). It is specific to design repositories, distinguishing it from projects or deploy repositories, though it does not explicitly contrast with the sibling openl_list_deploy_repositories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on using the 'name' field with other tools, notes case-insensitivity of id/name, and warns against inventing values. However, it does not specify when to avoid using this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations (auto-open for design repos, not for local), but does not disclose potential side effects or details about execution status/metadata. Annotations provide safety hints but description could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the purpose, then adding context and follow-up tools. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions returns execution status and metadata, but could be more specific about the return structure. However, it effectively complements the schema and points to result retrieval tools, making it fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description does not add significant meaning to parameters beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts project test execution and distinguishes behavior for design repositories vs local repo. It also mentions that results can be retrieved with specific sibling tools, but does not explicitly differentiate from other execution tools like openl_start_trace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about automatic project opening for design repos and directs users to result retrieval tools, but lacks explicit guidance on when not to use this tool vs alternatives (e.g., if project must be open or if running tests differently).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behaviors beyond annotations: row numbering (row 0 is header), effect on table location-derived ID when relocation occurs, and that the tool triggers a recompile. Annotations provide openWorldHint and idempotentHint, which are consistent with the overwrite operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the primary action and essential context. It is reasonably concise, though it could be slightly shorter by removing some redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key behaviors (not resized, ID volatility, recompile trigger) but lacks details about the return structure beyond the tableId. Given no output schema, more information on the response format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema already documents parameters. The description adds contextual meaning (0-based positions, row 0 as header, column 0 as labels), which is useful but not extensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action (overwrite cells of an existing row) and the resource (table row at a 0-based position). It mentions it operates on raw source for any table type. However, it does not explicitly differentiate from sibling tools like openl_update_table_cell or openl_append_table_rows, which serve similar functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to overwrite a row) but lacks guidance on when not to use it or alternatives. For example, it does not compare with openl_update_table_cell for single-cell edits or openl_insert_table_rows for adding rows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and open-world. The description adds return info (branch names, current branch, commit info) which is useful but not extensive. It does not disclose pagination behavior, latency, or other traits. With annotation coverage, the description's additional behavioral context is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states purpose and output, second gives usage guidance and a warning. It is front-loaded, concise, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema and a large sibling set, the description covers the key usage context (how to specify repository) and mentions return format. However, it omits explanation of pagination parameters (limit/offset) and response_format choices beyond the schema. It is minimally adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (repository and response_format have descriptions). The description adds significant semantic value for the repository parameter (accepts id or name, case-insensitive, don't invent) beyond the schema. However, limit and offset parameters are not explained. The description partially compensates for the schema gap but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all Git branches with metadata, using a specific verb ('List') and resource ('Git branches'). It implies use before switching/comparing versions, but does not explicitly distinguish from sibling tools like openl_create_project_branch. Still, the purpose is very clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use to see branches before switching/comparing, pass repository id or name from openl_list_repositories(), and avoid inventing values. It advises calling the repository list tool first if needed. No explicit 'when not to use', but the guidance is sufficient and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, and idempotent behavior. Description adds that it returns deployment names, versions, etc., but doesn't disclose additional traits like pagination behavior or potential for empty results. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no unnecessary words. Front-loaded with purpose and output summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with three optional parameters and no output schema, the description is reasonably complete. It states the output fields. However, it could mention that limit/offset control pagination or that results are from all production environments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33% - only response_format described), and the description does not explain the meaning of limit or offset parameters. Common pagination understanding partially compensates, but the description should have clarified these for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists all active deployments across production environments and returns specific fields like names, repositories, versions, and status. This verb+resource structure distinguishes it from siblings like openl_list_deploy_repositories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., openl_list_deploy_repositories or openl_deploy_project). The context implies it's for listing active deployments, but lacks when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include 'openWorldHint: true', indicating a mutation. The description confirms creation but does not disclose other behavioral traits like permission requirements, idempotency, or whether existing branches are overwritten. It adds some context about revision sources but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no redundant information. Every sentence is necessary and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose (creating a branch), the description covers the main functional aspect. However, it lacks details about the output/return value, which is absent from both description and output schema. For a creation tool, the outcome is fairly obvious, so this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds value by explaining the revision parameter's flexibility (specific revision, tag, branch) and default behavior. It also provides extra guidance for 'projectId' (use exact value from list output). This meaningfully supplements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (branch in a project's repository), with specific details about branching from revisions, tags, or other branches. It distinguishes from siblings like 'openl_list_branches' and 'openl_repository_project_revisions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining branching sources, but does not explicitly state when to use this tool vs alternatives, nor does it mention prerequisites (e.g., project must be open) or exclusions. No comparison to other branch-related tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint) already indicate safe read-only behavior. The description adds context about what the trace node includes and the source of node IDs, which is helpful and does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and efficiently provide the key source of input data. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and multiple siblings, the description adequately specifies inputs and output content. However, it could further differentiate from similar trace tools and clarify the response format beyond the parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, with three of four parameters documented. The description only reinforces the node ID source. The undocumented showRealNumbers parameter is not addressed, so the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get detailed trace node' and specifies the content: parameters, context, result, and errors. It also distinguishes from siblings by noting that node IDs come from openl_get_trace_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests using this tool after openl_get_trace_nodes, but does not explicitly state when to use it versus alternatives like openl_get_trace_parameter. No guidance on when not to use or prerequisites beyond node IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint as true, indicating safe, read-only behavior. The description adds the context of lazy loading but does not disclose additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. It contains no unnecessary words and is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (retrieving a single parameter value), complete schema coverage, and informative annotations, the description adequately covers the necessary context. The lack of an output schema is acceptable for this read-only operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The description does not add significant meaning beyond the schema; it only mentions parameterId in context of lazy loading. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a lazy-loaded parameter value and specifies the condition (lazy:true and parameterId set). The name and title reinforce this purpose, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('when a TraceParameterValue has lazy:true and parameterId set'), but does not provide guidance on when not to use it or mention alternative tools for non-lazy parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (openWorldHint), the description reveals critical side effects: ID volatility due to table relocation, recompile trigger, and response includes both current and previous table IDs. This fully discloses behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, front-loaded with purpose. While comprehensive, it could benefit from clearer structure (e.g., bullet points for key behaviors). No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers insert action, constraints, ID volatility, and recompile trigger. However, lacks explicit return value description (e.g., success/error shape) and no output schema to compensate. Still, high completeness for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds extra meaning: explains 0-based positions, appending behavior, and cells 2D array structure. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it inserts rows at a specified position in a table's raw source, with clear verb and resource. It does not directly differentiate from sibling tools like openl_append_table_rows, but the action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides operational context (works for any table type, position=height appends) and mentions response behavior. However, it lacks explicit guidance on when to use this tool versus alternatives like openl_append_table_rows or openl_update_table_row.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses async nature (202 Accepted) and websocket subscription for completion, including no manual polling needed. Adds value beyond openWorldHint annotation by detailing the workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, no wasted text. Efficiently covers asynchronous behavior and usage variants.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a start-trace tool: explains async, post-call, and variants. Lacks error handling details but sufficient given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds context about when to use inputJson vs testRanges, but schema already includes similar descriptions. Adds moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Start trace execution for a table' with specific verb and resource. It distinguishes between regular rules and test tables, providing different input methods. Implicit differentiation from siblings like openl_cancel_trace, but not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: for regular rules use inputJson with params, for test tables use testRanges. Also states post-action: call openl_get_trace_nodes once. Does not mention alternatives or when-not-to-use, but clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns a filtered summary and supports pagination. The annotation openWorldHint indicates possible external interactions, but the description does not contradict annotations. It could mention if the tool has side effects, but given read-only nature implied by description, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: first states the purpose, second explains what it returns and pagination, third gives a usage prerequisite. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, pagination, and a critical prerequisite. For a tool with 10 parameters, it could mention that it returns a summary with failure information, but the schema covers parameter details. No output schema exists, so description does not need to detail return structure beyond stating it returns a filtered summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds little beyond what the schema provides. It mentions pagination support, which is already in schema. The description does not add significant parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets test execution results filtered by a specific table ID, using verb 'Get' and resource 'test execution results' with the filter detail. It distinguishes from siblings like openl_get_test_results (likely unfiltered) and openl_get_test_results_summary (summary without table filter).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions a prerequisite: 'Use openl_start_project_tests() first to start test execution.' This guides the agent on when to use the tool. It does not explicitly state when not to use it or provide alternative tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses several behavioral traits beyond the minimal annotations: it operates on raw source, uses 0-based positioning (row 0 is header), explains id volatility (location-derived id changes when the table relocates), notes that the studio does not auto-compile and that this tool triggers a recompile, and details the response fields (tableId and previousTableId). This provides thorough transparency for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but efficient; each sentence adds value (e.g., id volatility, recompile behavior). It is front-loaded with the main action and uses clear structure. While it could be slightly more concise, the complexity of the tool justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (id changes, recompile, raw source operation) and the absence of an output schema, the description covers key aspects: how to structure cells, id handling, and side effects. However, it does not describe the complete response structure (e.g., whether it returns the table data) or error conditions, leaving some gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100%, the description adds significant meaning beyond the schema: it explains the cells structure as a '2D array', shows how to use '{ value: null }' for blanks, describes row/column orientation, and clarifies the behavior of tableId when it changes. This enriches the agent's understanding of parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add ONE OR MORE rows to the END of a table's raw source.' It specifies the verb 'add', the resource 'rows', and the location 'end', which distinguishes it from sibling tools like openl_insert_table_rows or openl_append_table_columns. The mention of 'raw source' and 'any table type' further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for appending rows to the end of a table but does not explicitly state when to avoid this tool in favor of alternatives (e.g., openl_insert_table_rows for inserting at a specific position). It mentions that it operates on raw source, which indirectly hints at limitations, but lacks direct guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds detailed behavioral traits: tableId volatility due to relocation, the tool reading the table to trigger recompile, and that subsequent openl_project_status reflects changes. It also notes operation on RAW source, applicable to all table types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but packs significant behavioral notes. It begins with the core action, then constraints, then additional context. However, it could be slightly more structured with bullet points for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the action, constraints, side effects, and required parameters well. No output schema exists, but it mentions key response fields (tableId, previousTableId). It is complete for a moderately complex tool with 5 parameters and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that positions are 0-based and row 0 is the header row, and that count defaults to 1. It also explains tableId volatility in more context, slightly exceeding schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it deletes one or more columns from a table's raw source, shifting columns left. It distinguishes from siblings by specifying it operates on columns and noting the inability to delete the leading-label column. The verb 'delete' and resource 'table columns' are clearly defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to delete columns) but does not explicitly mention when not to use or provide alternatives like row deletion or table deletion. No guidance on choosing between siblings like openl_append_table_columns or openl_insert_table_columns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behaviors: shifting columns, operating on raw source, table ID changes on relocation, recompile trigger, and response fields. No annotations contradict; openWorldHint is compatible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and each sentence adds value. It could be slightly more concise but is well-structured for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers most aspects needed for correct use: insertion logic, table ID behavior, recompile trigger, and cells array format. The position indexing inconsistency slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already documents parameters. The description adds minimal value and creates confusion by stating 'position is 1..width' while also saying 'positions are 0-based', which contradicts the schema's minimum of 1.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Insert ONE OR MORE columns at position' and specifies the resource (table columns) and verb (insert). It distinguishes from siblings like openl_append_table_columns by mentioning insertion at a position rather than appending.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (to insert columns at a specific position) and provides context about table ID volatility and recompile triggering, but does not explicitly compare to alternatives like openl_append_table_columns for end-of-table insertion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond annotations: it explains that the tool is read-only, local (never calls OpenL Studio), and that it returns only metadata. It also describes the source of the data (bundled documentation at a specific release tag), which is not covered by readOnlyHint or idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient but dense, packing key information into a single paragraph. It uses dashes and semicolons to separate ideas, but could benefit from bullet points for readability. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, filtering, pagination, and relationship to a sibling tool. However, it does not mention the response_format parameter or explain the return structure beyond listing metadata fields. Given the simplicity of the tool, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has descriptions for 3 of 5 parameters (type, search, response_format) providing 60% coverage. The description adds context for pagination (limit/offset) but does not elaborate on response_format. Overall, it adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to list metadata of OpenL reference documentation, explicitly noting it returns only metadata and directing to openl_get_guides for bodies. It distinguishes from siblings by specifying the scope and linking to the complementary tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (listing metadata) and directs to openl_get_guides for full content. It mentions filtering and pagination but does not explicitly state when not to use it or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing support for branches and revisions, and indicating the tool is a precursor to modifications. The openWorldHint annotation is not contradicted; the description aligns with opening projects for editing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that front-load the core purpose and quickly cover the key features (branches, revisions) and usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the main action and usage, it lacks details on return values, error cases, and prerequisites (e.g., project must exist). The response_format parameter hints at output, but the description does not elaborate. Given no output schema, some additional context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds extra context by emphasizing that 'projectId' must be taken directly from list_projects, and explains that 'branch' and 'revision' serve specific purposes. This enriches the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Open a project for editing' with a specific verb and resource, and distinguishes from sibling tools like openl_create_project and openl_close_project by focusing on opening existing projects for modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this before making changes to project tables or rules,' providing clear context for when to use. It implicitly excludes read-only operations and does not mention alternatives, but the guidance is sufficient for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true, and the description adds context about session-based project context and the limitation regarding the 'local' repository. It does not contradict annotations and provides useful behavioral details beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the main purpose, and includes all essential usage information without unnecessary details. Every sentence is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description does not explain the return value or outcome. While the key points are covered, completeness could be improved by stating what the response indicates. However, for a relatively simple destructive tool, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by specifying the source of historyId (from list_project_local_changes) and clarifying the session-based context, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool restores a project to a specified version from local history, using a specific verb and resource. It distinguishes itself from the sibling tool openl_list_project_local_changes by noting the source of the historyId.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions using historyId from openl_list_project_local_changes response, and notes the requirement that the project must be opened first and that it's not available for the 'local' repository. This provides clear guidance on when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing that the header row cannot be deleted, the table ID is volatile and changes when the table relocates, the tool triggers a recompile by reading the table back, and the response includes previousTableId. These are critical behavioral traits not covered by destructiveHint or openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise given the complexity, with the main action in the first sentence. It is logically structured: action, parameters, special behaviors. A few minor redundancies exist, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description explains the return values (current tableId and optional previousTableId) and side effects (recompile trigger). It adequately covers the tool's behavior, making it complete for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds meaning by explaining that positions are 0-based, the header row cannot be deleted, and the tableId volatility rationale. It also clarifies that the response returns current and previous tableId, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes rows from a table's raw source at a given position, with a default count of 1. It distinguishes itself from sibling tools like openl_delete_table (whole table) and openl_delete_table_rows is unique, so purpose is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that it works for any table type via raw source, but does not explicitly state when to use this tool versus alternatives like openl_delete_table or openl_update_table_row. Lacks clear guidance on when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds value by stating 'Takes no arguments and never calls OpenL Studio,' which goes beyond the annotations and provides further behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three sentences with no wasted words. It is front-loaded with key information: 'Read-only. Call this FIRST,' and each sentence contributes meaningfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description covers the essential context: what it returns, order of use, and that it never calls OpenL Studio. It is sufficiently complete for a simple initialization tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%. With no parameters, the description doesn't need to add parameter information, and the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it returns the mandatory workflow protocol and workspace orientation. It explicitly says to call this first before any other openl_ tool, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'Call this FIRST, once per session, before any other openl_ tool.' It also explains when to call openl_get_project_agent_context and mentions related documentation tools, offering clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the tool's behavior: it returns aggregated statistics without testCases array. This adds context beyond the openWorldHint annotation, which merely hints at read-only. The description clarifies the output scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is incredibly concise: two sentences covering purpose and prerequisite. No extraneous words, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (4 params, no output schema), the description covers the key points: what it returns and the prerequisite. It could mention error states (e.g., if no tests started) but overall is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the input schema fully describes parameters (100% coverage), the description adds value by providing usage context for 'projectId' (exact value from openl_list_projects()) and summarizing response_format options. This aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get brief test execution summary without detailed test cases.' It specifies the verb (Get), resource (test execution summary), and what it returns (aggregated statistics). This distinguishes it from sibling tools like openl_get_test_results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a prerequisite: 'Use openl_start_project_tests() first to start test execution.' It implies when to use this tool (for summary) versus others for detailed results, but does not explicitly exclude using it when detailed cases are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds critical behavioral information beyond annotations: table ID mutability and staleness after updates/append operations. This complements the readOnlyHint (true) by describing the transient nature of output values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and resource, then efficiently conveys output usage and a critical warning. No extraneous sentences; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the key returned field (tableId) and its role. Could include a full list of returned fields, but the main purpose is clear and the warning about staleness compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, so the schema already documents most parameters. The description mentions 'type, name, and file' filters but doesn't elaborate on parameter specifics beyond the output usage. Adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'tables/rules in a project' with optional filtering. It distinguishes from sibling tools like openl_get_table (single table) and openl_update_table (modification) by focusing on listing and metadata retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides practical guidance on using the output 'tableId' for subsequent API calls and warns about stale IDs after edits. Lacks explicit exclusions or comparisons to alternatives, but the context is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide openWorldHint:true, which is minimal. The description compensates by disclosing key behaviors: automatic folder creation, source deletion after move, collision handling (HTTP 409), staging nature (working copy), and branch pinning. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus brief bullet-like points. Every sentence adds value—purpose, API mapping, behavioral details, staging info, branch guidance. No redundancy or fluff. Front-loaded with core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (3 required) and no output schema, the description covers the main behaviors: auto-creation, deletion, collision, staging, branch. It mentions when to commit. Could add return type info, but overall it's fairly complete for a file operation tool with good sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond schema by explaining that intermediate folders are created automatically for destinationPath, and that branch is used to pin the project's branch with details on when to omit. Examples given for sourcePath and destinationPath. This incremental value justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves or renames a file within a project, using specific verbs 'Move or Rename' and resource 'Project File'. It distinguishes from sibling tools like openl_copy_project_file, openl_delete_project_file, and openl_write_project_file by specifying the unique combination of move/rename, automatic folder creation, source deletion, and staging in working copy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: use this to rename or relocate a file. It explains that intermediate folders are created automatically, source is deleted, destination collision fails with 409, and the move is staged (commit with openl_save_project). It mentions branch usage to pin project's branch. No explicit when-not-to-use, but context is sufficient to distinguish from copy, write, delete siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the openWorldHint annotation, the description reveals key behaviors: creates a new revision, transitions project to OPENED, validates if endpoint available, and optional close behavior. No contradictory or hidden information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences, front-loaded with the main purpose, and each sentence adds essential information without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters, the description covers prerequisites, behavior, and state transitions adequately. It omits return value details but that is acceptable as output schema is absent. The tool's complexity is moderate and description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds value by explaining the comment parameter's role as commit message and the closeAfterSave parameter's one-request behavior, going beyond the schema hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves project changes to Git, with specific verb 'Save' and resource 'project changes'. It distinguishes from siblings like openl_close_project and openl_create_project by focusing on saving/committing. The precondition (EDITING status) and outcome (new revision, OPENED) are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use: 'after update_table, append_table, or other edits', and when not: 'Does not work for repository local' and 'Works only when project status is EDITING'. It does not explicitly name alternatives but provides sufficient context given the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate openWorldHint and idempotentHint, but the description adds critical behavioral details: table ID volatility on relocation (with 'previousTableId' tracking), recompile triggering, and the response format. These go beyond annotations and help the agent understand side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is information-dense but not excessive. Every sentence adds value (action, scope, positioning, ID behavior, recompile note). It is front-loaded with the primary action. Minor redundancy could be tightened, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and complex side effects, the description covers: input meaning (positions, IDs), output behavior (current/previous tableId), lifecycle (relocation, recompile trigger), and effect on studio state. It is sufficiently complete for an agent to invoke correctly and handle responses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so baseline is 3. The description adds value by explaining 0-based positioning (header row = row 0, leading labels = column 0) and notes tableId's volatility. This helps interpret parameter semantics beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (unmerge merged table cells) and specifies the operand (a table's raw source, any table type). It uses strong verbs ('unmerge', 'split') and distinguishes from the sibling tool 'openl_merge_table_cells' by being its inverse. The details about positions and recompile behavior further clarify purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context, including the effect on table ID when relocation occurs and the recompile trigger. However, it lacks explicit when-to-use vs alternatives (e.g., when to use this vs other table editing tools) and does not state prerequisites or exclude scenarios. The context is clear but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: no overwrite option (HTTP 409), automatic intermediate folder creation, staging in working copy requiring commit, and branch pinning behavior. Given the openWorldHint annotation, this provides sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the core purpose. Every sentence adds valuable information: purpose, REST mapping, auto-creation, no-overwrite, staging, branch usage, and use cases. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain the success response or failure modes beyond the 409. It also omits what happens if sourcePath does not exist or if permissions are insufficient. While adequate for many use cases, it could be more complete for a mutation tool with openWorldHint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning for destinationPath (auto-create, no overwrite) and branch (pinning to project's branch), which goes beyond the schema descriptions. Response_format is not elaborated but the enum covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool copies a file within a project to a new project-relative path, using a specific verb and resource. It distinguishes from siblings by providing use cases ('scaffold a new module from an existing one or clone a test set') and implicitly contrasts with move/write via the 'copy' action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (scaffolding/cloning) and includes critical constraints (no overwrite, need to commit, branch pinning). It does not explicitly compare to sibling tools like move or write, but the usage context is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it waits for trace completion via websocket, can clear trace from memory with release, and explains the 409 conflict during runtime. Annotations already indicate read-only and idempotent, but the description provides the actual mechanism.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative and well-structured, front-loading the core purpose. It is somewhat long but each sentence adds necessary detail about waiting, release, tableId, and timeout. Minor redundancy but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, 1 required, no output schema), the description covers the essential behavioral nuances like waiting, release, and tableId for cross-process scenarios. It does not detail the output format but that is documented in the response_format parameter. Overall sufficiently complete for an export tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%), so baseline is 3. The description adds value beyond schema for key parameters: it clarifies tableId's optionality under different scenarios, wait's default behavior, and waitTimeoutMs's default/cap. For other params like response_format and showRealNumbers, it adds little.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a trace as plain text and returns full trace content. The verb 'export' and resource 'trace' are specific, and it distinguishes from sibling tools like openl_cancel_trace or openl_get_trace_nodes by focusing on the complete export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it (after starting a trace, during a running trace it handles 409 by waiting via websocket) and when to pass tableId (for traces started by other processes). It does not explicitly compare to alternative tools but provides enough context for the typical workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide openWorldHint: true, but the description adds significant behavioral context: pagination groups results by table, and it supports filtering failures and different response formats. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph covering key points without unnecessary detail. It is well-structured and front-loaded with the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description provides sufficient detail about return values (testCases grouped by table), pagination behavior, filtering, and prerequisites. It covers all essential aspects for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description goes beyond the schema by explaining pagination applies to tables, not test cases, and that projectId should come from openl_list_projects(). It also clarifies response_format options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full test execution results with pagination support, and specifies it returns a summary including testCases array grouped by table. This differentiates it from sibling tools like openl_get_test_results_by_table and openl_get_test_results_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs users to call openl_start_project_tests() first, and explains that pagination applies to test tables, not individual test cases. It does not explicitly state when not to use this tool, but the context is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and open-world behavior. The description adds important behavioral context: session-based project context, requirement for project to be opened, and the limitation for 'local' repository. This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a short summary followed by important notes in separate sentences. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description fully explains the output contents and all necessary context for correct invocation (prerequisites, limitations, session-based context). It is complete for a read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter (response_format) with 100% description coverage, including enum values and defaults. The tool description does not add additional parameter information beyond the schema, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'list' and the resource 'local change history for a project', including details on the returned data (versions, authors, timestamps, comments). It distinguishes itself from sibling tools by focusing on local changes and mentioning prerequisites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (project must be opened via openl_open_project) and when not (not available for repository 'local'). Also clarifies that no projectId parameter is needed due to session-based context, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations by disclosing that the edit may relocate the table (changing its id), that it reads the table back to trigger recompile, and that the top-left cell's value is preserved. Annotations (openWorldHint, idempotentHint) are consistent with this behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but each sentence adds value. Information is front-loaded with purpose, then constraints and side effects. Could be slightly more concise by grouping related details, but it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description covers all essential aspects: what the tool does, constraints (range must be >1 cell, within table), coordinate system, id volatility, recompile trigger, and response contents. Provides a complete mental model for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds useful context: coordinate system details, tableId volatility explanation, and response_format options. It enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it merges a rectangular range of cells into one, keeping the top-left cell's value, and operates on the table's raw source. It implicitly distinguishes from unmerge via sibling name, but does not explicitly contrast with other table editing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: positions are 0-based, row 0 is header, column 0 is labels; warns that the table's id may change upon relocation; instructs to use the returned 'tableId' for subsequent calls; notes the tool triggers a recompile. This helps the agent decide when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate read-only, idempotent, and open-world. The description adds behavioral context: it returns a list of revisions with specific fields, supports pagination and filtering, and explains the repository parameter flexibility. This adds value beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each adding distinct value: the first states the purpose, the second details output, the third mentions features, and the fourth gives parameter guidance. No fluff, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For 8 parameters (2 required) and no output schema, the description covers the key aspects: output content, pagination, filtering, and parameter sourcing. It could elaborate more on page/size defaults, but the schema already handles those. Overall, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds considerable meaning: it explains the repository parameter with concrete guidance (use values from openl_list_repositories(), case-insensitive), provides example project names, and describes the response_format enum options. This surpasses the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets revision history (commit history) of a project, listing commits with hashes, authors, timestamps, and types. This is a specific verb+resource that is distinct from sibling tools like openl_list_projects or openl_get_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on how to obtain the repository identifier using openl_list_repositories(), warns against inventing values, and explains the case-insensitivity. It also mentions pagination and filtering capabilities. However, it does not explicitly compare to sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare openWorldHint=true and idempotentHint=true. The description adds critical behavioral details: edit may relocate table (changing its ID), response returns current tableId and previousTableId when changed, and the tool triggers a recompile by reading the table back. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences with no fluff. Each sentence adds value: purpose, value explanation, raw source applicability, index conventions, ID volatility, and recompile behavior. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description covers all key aspects: parameter usage, side effects (ID change, recompile), and index conventions. It is complete for an agent to correctly invoke the tool, given the required parameters and behavioral notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaning beyond the schema: it explains that value is required, positions are 0-based, row 0 is header, column 0 is labels, and the volatility of tableId. This provides valuable context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a single cell at a given (row, column) in a table's raw source. It specifies the value can be string/number/boolean or null to clear. The title 'Update Table Cell (raw)' matches the description, and it distinguishes from sibling tools that operate on full tables, columns, or rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use: it works on the raw source for any table type. It mentions 0-based positions and that row 0 is header, column 0 is labels. It does not explicitly contrast with siblings like openl_update_table_range or openl_update_table_row, but the unique purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior (destructiveHint=true). The description adds value by detailing the workflow for unsaved changes, including the requirement for user confirmation when discarding, which prevents accidental data loss.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the primary action, and every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description covers the essential workflow for closing a project with unsaved changes. However, it does not describe the return value or post-close state, which would be slightly helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The overall description adds meaning by explaining the interplay of saveChanges, discardChanges, and confirmDiscard parameters, providing context beyond individual schema entries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (close) and resource (project), distinguishing it from sibling tools like openl_save_project or openl_open_project. It also specifies the handling of unsaved changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool and how to handle unsaved changes: either save with a comment or discard with user confirmation, including the confirmDiscard parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits beyond the openWorldHint annotation: the backend rejects unknown/extra fields with a 400, there is no 'signature' field, tables require exact case-sensitive tableType, and the response contains metadata not compilation results. It recommends calling openl_project_status afterward, adding transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a lengthy wall of text, dense with information but lacking structural breaks like bullet points or sections. While every sentence earns its place for a complex tool, the readability could be improved. It is front-loaded with core purpose but the detailed parameter guidance could be better organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 table types, many fields, no output schema), the description is remarkably complete. It covers prerequisites, pitfalls, examples, and post-creation steps. For a creation tool, the response metadata description is sufficient and the advice to check project status afterward addresses completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds immense value: it explains each oneOf branch for 'table' with examples, pitfalls (case-sensitivity, missing fields), and tips (using openl_get_table for reference). It also clarifies moduleName (modules = .xlsx files, default 'Main'), projectId (exact from list_projects), and response_format options. This far exceeds minimal schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new table/rule in an OpenL project with specific verb and resource. It distinguishes from siblings by being the recommended creation tool and lists diverse use cases (Rules, Spreadsheet, Datatype, etc.). The action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive usage guidance: it is the recommended tool for creation, lists use cases, and explains prerequisites (moduleName must exist, table structure must be complete). It implicitly excludes misuse by detailing required fields and pitfalls. However, it does not explicitly contrast with sibling tools like openl_update_table or openl_append_table.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (destructiveHint: true, openWorldHint: true) are supplemented with rich context: auto-cleans dangling references, deletion is staged, and requires a separate commit. This goes well beyond the simple destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each earning its place: action, API mapping, side effect, usage scenario, and warning. Front-loaded with the core verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects for a delete tool: what it does, parameter nuances, side effects, and commit requirement. No output schema is expected for a delete; however, error conditions (e.g., nonexistent path) are not mentioned. Reasonably complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value: clarifies that paths are project-relative and must not include the project name, explains the trailing slash convention for folders, and instructs to use the exact projectId from openl_list_projects(). The branch and response_format parameters are sufficiently explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a file or folder by project-relative path, maps to a specific API endpoint, and distinguishes its use case ('remove legacy assets or deprecate docs') from sibling tools like openl_move_project_file or openl_write_project_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('remove legacy assets or deprecate docs') and explains the staging/commit workflow ('Like writes, the deletion is staged in the working copy — commit it with openl_save_project'). Mentions branch pinning but does not explicitly contrast with alternatives like openl_write_project_file for replacing content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. Description adds key behavioral details: entire table area is cleared, table no longer exists after recompilation, stale ID resolution, and that the studio does not auto-compile immediately. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four clear sentences, each adding unique value. Front-loaded with purpose, then scope, alternatives, stale ID handling, and post-step advice. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: what it does, scope, alternatives, stale ID, post-delete check. Lacks explicit mention of return value or confirmation, but overall complete for a deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. Description adds marginal value by noting tableId can go stale and auto-resolution, but does not significantly enhance understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Delete an ENTIRE table from a project' with specific verb and resource. It distinguishes from sibling tools that delete rows/columns by explicitly naming them. The scope is clearly defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool vs alternatives, e.g., 'To remove only a row or column WITHIN a table, use openl_delete_table_rows / openl_delete_table_columns instead.' Also advises to run openl_project_status afterward to check for dangling references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds details about parameter flexibility (case-insensitivity) and that features are queried from a repository. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two precise sentences plus parameter-specific guidance. Every part contributes without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core usage well. Lacks explicit return structure (no output schema), but response_format parameter allows flexibility. Adequate for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for both parameters. Description reinforces the repository parameter's semantics (accepts id or name, case-insensitive, must call list_repositories first), adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly specifies 'Get features supported by a design repository' with examples (branching, searchable). Distinct from sibling tools like openl_list_repositories and openl_list_branches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when to use: before operations depending on features. Also provides precise parameter guidance: pass id or name from openl_list_repositories(), case-insensitive, and warns against inventing values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint and idempotentHint, but description goes far beyond by detailing behavior for files vs folders, encoding modes, client-side slicing, memory implications, and MCP message limit warnings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is verbose but well-structured with numbered scenarios, front-loading the main purpose. Every sentence adds value given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description comprehensively covers return types (content, base64, metadata, listing, ZIP) and error conditions (404 for unknown version), leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but description adds meaningful context beyond schema, such as path behavior for '/' ending, offset/length caveats with multi-byte characters, and auto-encoding detection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads any file or folder in a project by path, distinguishing it from sibling tools like openl_write_project_file and openl_search_project_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit examples of when to use (e.g., reading AGENTS.md, README.md, schemas) and implies alternatives via sibling tools, but lacks explicit when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors beyond annotations: table not resized, operates on RAW source, id can change on relocation, and recompile trigger by reading table back. Annotations are sparse (openWorldHint, idempotentHint), so description carries burden well. No contradiction between description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, front-loaded with main action, then constraints, then important behavioral details. Every sentence adds unique value without redundancy. Highly efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers major aspects: action, constraints, id changes, recompile behavior. Missing details on response structure beyond tableId, but acceptable given no output schema. For a mutation tool with volatile id, it provides sufficient context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds value by explaining position's 0-indexing including header and leading labels, cells array usage (one per row), and tableId volatility. Provides context beyond schema descriptions, justifying a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool overwrites cells of an existing column at a given position in a table's raw source. Specifies the action (overwrite), resource (column), and scope (top to bottom, not resized). Distinguishes from sibling tools like openl_update_table_cell and openl_update_table_row by focusing on column operations and mentioning RAW source applicability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use: to overwrite an entire column. Implicitly distinguishes from alternatives by not mentioning row/cell operations. States the table is not resized, hinting at other tools for insertion. However, does not explicitly name alternative tools or list scenarios when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (openWorldHint, idempotentHint), it discloses critical behavior: table ID volatility when relocation occurs, and that the tool triggers a recompile by reading the table back. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative and front-loaded with the main action. Each sentence adds necessary detail, though slightly lengthy. Well-structured without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains response contents (current tableId, previousTableId) and side effects (recompile trigger). Covers all key aspects for correct invocation and subsequent steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema: explains 'cells' structure, 0-based indexing, table ID volatility, and project ID usage. Enriches understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it overwrites a rectangular range of cells in a table's raw source, anchored at a top-left cell. It explicitly differentiates from the sibling tool openl_update_table_cell for single cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear constraints (range must cover more than one cell, fit within table) and explicitly recommends openl_update_table_cell for single cells. However, it does not compare with other range-based siblings like openl_update_table.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond openWorldHint annotation, description discloses key behaviors: 0-based positions, table relocation changes id, response returns current id, and triggers recompile. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise (<150 words), well-structured: purpose first, then cells format, then behavioral details. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: operation, parameters, behavioral edge cases, and response contents (tableId, previousTableId). No output schema needed given detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds clarity: explains cells as 2D array and clarifies tableId volatility. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Add ONE OR MORE columns to the END of a table's raw source,' with specific verb and resource. Distinguishes from siblings like openl_insert_table_columns (inserts at position) and openl_append_table_rows (appends rows).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context: operates on raw source, works for any table type, and notes id volatility. Implies when to use (appending columns) but does not explicitly contrast with alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully explains behavioral details beyond annotations: the two creation modes, atomic commits, indexing after clone, and that branch clones may not appear immediately in listing. It also notes that blank projects are created on the default branch. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for each mode and bullet points, making it scannable. Though relatively long, every sentence adds value. Slight improvement could be more concise phrasing, but it effectively communicates complex behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return values (new project name and commit revision), error codes (409, 404, 403), prerequisites (calling list functions), and behavioral nuances (branch indexing delay). For a tool with no output schema, it provides complete context for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3, but the description adds extensive meaning: it clarifies the template parameter's dual role (omit for blank, pass name for clone), warns against inventing repository values, explains when branch is honored, and details the commit comment default and when it applies. This goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or clones an OpenL project, distinguishing two modes (CREATE and CLONE) with specific behaviors. It identifies the resource (design repository project) and the action (committed creation), making it distinct from siblings like openl_close_project or openl_deploy_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises calling openl_list_repositories() or openl_list_projects() first and explains when to omit or include the template argument. It warns about errors (409, 404, 403) and branch behavior for clones. However, it does not explicitly compare with alternative tools for similar tasks, missing some guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and open-world behavior. The description adds critical behavioral context: tableId volatility, automatic resolution of stale IDs, and the limitation of raw output for update operations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and concisely explains the two modes, use cases, and important caveats. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, no output schema), the description covers all necessary aspects: output types, when to use each, id behavior, and how to handle staleness. It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds marginal value. However, it provides meaningful context for the raw parameter (usecases) and the tableId parameter (volatility and automatic resolution), which enriches understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a specific table/rule, and distinguishes between parsed and raw modes. It explicitly contrasts with the update tool, differentiating itself from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use raw=true (unknown/custom table types) and notes that raw output cannot be used with openl_update_table. Also addresses staleness of tableId and recommends refresh via openl_list_tables(). Does not explicitly list all alternatives but gives sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the wait functionality, progress notifications, compile state reflection, and the caveat about edits bypassing certain tools. It fully aligns with annotations (readOnlyHint, openWorldHint, idempotentHint) and adds significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of moderate length. It effectively front-loads the purpose but could be structured into bullet points for easier scanning. The content is dense but not overly verbose, earning a high score for conciseness despite minor structure improvements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers key aspects: what it returns, when to use it, and how it interacts with other tools. The lack of detailed output structure is partially mitigated by listing return types. For a tool with no output schema, this is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While input schema covers 100% of parameters with descriptions, the tool description adds meaning by explaining the wait behavior, branch mismatch handling, severity sorting, and response_format options. This enriches understanding beyond what the schema provides, though the schema itself is already detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the post-compilation status of a project', specifying the verb 'Get' and the resource 'post-compilation status'. It distinguishes itself from sibling tools like table edit tools by emphasizing it is read-only and does not trigger compilation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use the tool (for reading status after edits) and when not to (when compilation is needed). It details the wait parameter behavior and how status reflects changes made through specific tools, providing clear alternatives and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint, but the description adds critical behavioral details: recursive defaults to false, '**' glob does not descend without recursive=true, scope differences (SUBTREE vs ANCESTORS), client-side pagination behavior, and branch pinning semantics. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the core purpose first, followed by important caveats and examples. While it is detailed, every sentence serves a purpose. It could be slightly trimmed (e.g., the 'IMPORTANT' warning could be shorter) but overall is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value (matching nodes with path, name, type, size, pagination metadata). It covers all key parameters, behaviors, and use cases. The examples and notes on recursive and scope make the tool fully understandable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 86% (high), so baseline is 3. However, the description adds significant value beyond the schema: it explains the recursive parameter's critical nuance (default false, '**' need recursive), scope behavior, pagination metadata, and provides example patterns. This justifies a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches project files and folders by multiple criteria (ant-glob pattern, extensions, type, content substring). It includes a concrete mapping to the API endpoint and gives example queries that distinguish it from sibling tools like listing or reading files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (e.g., 'where is portability loading mentioned?', 'list every xlsx under rules') and provides examples. It does not explicitly state when not to use it, but the sibling tool list and the specific use cases imply its niche. Given the clarity of the examples, a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits beyond annotations: table ID can change if relocated, recompile is triggered, RawSource row width requirements, and that rows with wrong cell count are rejected before writing. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense and informative, front-loaded with core purpose. Slightly long but well-structured and each sentence adds necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Thoroughly covers all table types' payload structures, important side effects (id change, recompile), and response behavior. No output schema, but description adequately explains what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds value by summarizing the payload structure per tableType and clarifying RawSource format, but some details are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add new rows/fields to an existing table (additions only)' with a specific verb and resource. It distinguishes from sibling tool 'update_table' for modifications, deletions, or reordering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'For modifying, deleting, or reordering use update_table instead.' Also provides important context about when to use (additions) and when not to (other operations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, and open-world. Description adds critical details like 'projectId' usage, repository parameter display name requirement, and caveats for local-only projects, enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively long but efficiently packed with essential information, front-loaded with purpose and caveats. Minor redundancy could be trimmed, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description fully explains return fields and behavior. Addresses edge cases like local-only projects and provides complete guidance for a complex tool with 6 parameters and nested objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 67% of parameters with descriptions. The description adds value for repository (use display name) and tags (prefix handled automatically), but limit/offset/status/response_format are not further elaborated beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'list', resource 'projects', and scope with optional filters. Distinguishes from sibling tools like openl_get_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and when-not-to-use guidelines, including handling local-only projects and referencing openl_list_repositories() for valid repository names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors such as committing saves all pending changes, works only for design repositories, default folder creation, and conflict policies. Adds valuable context beyond the openWorldHint annotation, such as the distinction between byte replacement and table changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and front-loaded main action. Slightly verbose but every sentence adds value. Could be marginally more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 9 parameters and no output schema, the description thoroughly covers all aspects including encoding, commit, conflict policy, branch, folder creation, and response format. Provides sufficient context for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining the commit/working copy distinction, encoding implications, conflict policy behavior, and projectId formatting requirements, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create or replace a file in a project by its project-relative path', specifying both verb and resource. It distinguishes from sibling tools like openl_append_table and openl_update_table by noting when to use those instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on encoding selection, commit vs working copy behavior, conflict policy, branch pinning, and when to use alternative tools for table modifications. Includes both when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds key behaviors: never calls OpenL Studio (local), returns verbatim without truncation, fails with error naming unknown ids. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three concise sentences, each adding essential information. Front-loaded with the main action, no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully compensates by stating return format (full markdown), truncation behavior (none), error handling (fails for unknown ids), and prerequisite (use list_guides). Complete for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description already explains the parameter semantics. The description reinforces the size_bytes note and adds context about error behavior for invalid ids, providing additional value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns full markdown bodies of bundled documents by exact ids, distinguishing it from sibling openl_list_guides which lists guide metadata. It specifies the action (return bodies), the resource (guides by id), and scope (full, verbatim).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to look up ids with openl_list_guides first, warns about unknown ids failing, advises to mind size_bytes and fetch only what is needed. This provides clear when-to-use and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, openWorld, idempotent), the description details the upward traversal, concatenation order, skipping of missing levels, and listing of reference guide ids. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds necessary information; front-loaded with primary use. No wasted words despite length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description fully explains the return value (concatenated markdown or 'no files' note) and mentions related guide retrieval. Complete for a read-only retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by explaining the 'folder' parameter's use for deeper file context and reminding to use exact 'projectId' from list. Slightly above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: resolving agent guidance (AGENTS.md hierarchy) for a project. It distinguishes itself from the sibling 'openl_search_project_files' by noting that for file-level search, use that instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'call this BEFORE working on or creating anything in the project', providing clear context for when to use. Also mentions alternative for subtree search, aiding decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: tableId volatility (changes when table relocates), return fields (tableId and previousTableId), and that the tool reads the table back to trigger recompile (studio does not auto-compile). This goes well beyond the idempotentHint and openWorldHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but well-structured with warnings, steps, and notes. It is front-loaded with the core purpose. Every sentence provides essential guidance for correct usage. Could be slightly condensed, but the detail is justified given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested object, volatile IDs, compile implications, required workflow), the description covers all critical aspects: how to obtain the table, what to include, how to handle tableId changes, response behavior, and side effects. No output schema exists, but description sufficiently describes return values. Complete context for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds extra meaning: for 'view' it explains the full structure requirement, workflow, and field constraints; for 'tableId' it explains volatility and how to obtain; for 'projectId' it stresses exact value; for 'response_format' it explains each option. Adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replaces the entire table structure and lists specific use cases (modifying, deleting, reordering rows, structural changes). It distinguishes itself from the sibling 'openl_append_table' by specifying when not to use it. The verb 'Replace' and resource 'Entire Table' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (modifications, deletions, reordering) and when-not-to-use (simple additions, use append_table). Includes a required workflow with steps (get_table, modify, send full object). Also discloses critical behavioral details like tableId volatility and compile behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behaviors beyond annotations: the 409 Conflict response while trace is running, automatic websocket subscription to wait for completion, default and max wait time, and the effect of the 'wait' parameter. These are not covered by annotations (readOnlyHint, openWorldHint, idempotentHint).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose and key behavior. Every sentence adds value without redundancy. It efficiently covers usage, parameters, and edge cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and the absence of an output schema, the description sufficiently explains what the tool does, when to use it, and how parameters affect behavior. It covers the waiting mechanism, error handling (409), and cross-process usage, making it self-contained for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the input schema. For example, it explains that 'nodeId' omitted returns root nodes, 'tableId' is optional when same server instance but required for cross-process traces, and 'wait' controls immediate vs. polling behavior. This contextualizes the parameters far beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get trace node children (or root nodes if nodeId omitted)', using a specific verb and resource with scope. It distinguishes itself from sibling tools like openl_start_trace and openl_get_trace_node_details by indicating it retrieves a tree structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite ('Use openl_start_trace first'), explains the default waiting behavior with timeout, and provides guidance for when to pass 'tableId' (trace started by another process). Also describes how to bypass waiting by setting 'wait: false'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![openl-mcp MCP server](https://glama.ai/mcp/servers/openl-tablets/openl-mcp/badges/card.svg)](https://glama.ai/mcp/servers/openl-tablets/openl-mcp)

Score Badge

Copy to your README.md:

[![openl-mcp MCP server](https://glama.ai/mcp/servers/openl-tablets/openl-mcp/badges/score.svg)](https://glama.ai/mcp/servers/openl-tablets/openl-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/openl-tablets/openl-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server