Rootr MCP Server
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools have distinct purposes, with clear domain separation (documents, databases, CRM, presentations, etc.). Overlaps exist within domains (e.g., rootr_read_database vs rootr_list_rows) but descriptions clarify when to use each. Overall, an agent can distinguish tools well.
Naming Consistency4/5All tools start with 'rootr_' and use snake_case verb_noun pattern. However, verb choice varies (list/read/get, upsert/create/update) and some tools mix actions (e.g., rootr_crm_upsert_company covers create, update, delete). Mostly consistent but with minor deviations.
Tool Count2/581 tools is excessive for most use cases. While the server aims to be comprehensive, this many tools can overwhelm agents and increase selection errors. A more focused set (20-30) would be more appropriate for typical workspace management.
Completeness4/5The tool set covers CRUD and advanced operations for many node types: documents, databases, spreadsheets, presentations, CRM (companies, contacts, deals, activities, tasks), issue trackers, logs, forms, whiteboards, and more. Minor gaps like user management exist, but overall it's quite complete for the workspace domain.
Average 4.3/5 across 81 of 81 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about the CRM node and auto-linking to the knowledge graph, which informs the agent about the tool's ecosystem. However, it does not disclose what 'full detail' includes or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences. The first sentence front-loads the core action. The second sentence provides context but is not essential for tool invocation. Could be slightly more concise, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and annotations present, the description covers the action and context. However, with no output schema, the description should clarify the return structure (e.g., 'full detail' is vague). The missing return details leave the agent uncertain about the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for 'dealId' ('Deal id'). The tool description does not add further meaning to the parameter, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('fetch full detail') and the resource ('ONE Rootr CRM deal by id'). It distinguishes from list-oriented siblings by specifying 'ONE' deal. However, it does not explicitly contrast with sibling tools like rootr_crm_get_company or rootr_crm_list_deals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., rootr_crm_list_deals for multiple deals, or rootr_crm_upsert_deal for mutations). The description only states what the tool does, not the context for its use.
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 declare readOnlyHint=true and destructiveHint=false. Description adds that it lists activities but does not disclose additional behavioral traits such as pagination behavior, response format, or any limitations. With annotations covering safety, the description provides minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences: first states core purpose, second provides CRM context. No redundant information, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and annotations present, the description leaves gaps: no return value explanation, no pagination details, no behavior when combining filters. The second sentence is promotional rather than informative about tool specifics. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 57%. Description explains that filtering is possible by contact, company, deal, or activity type, which maps to parameters type, contactId, companyId, dealId. However, it does not explain required parameter crmId or pagination parameters limit and offset. Partial compensation for missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'list', resource 'activities', and mentions filtering by contact, company, deal, or activity type. This distinguishes it from sibling CRM list tools like rootr_crm_list_companies, rootr_crm_list_contacts, rootr_crm_list_deals, and rootr_crm_list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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., rootr_crm_list_tasks). The description only mentions it is part of a CRM node but does not provide context for choosing this tool over siblings for activity-related queries.
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=true and destructiveHint=false, so the read-only nature is clear. The description adds no additional behavioral traits (e.g., rate limits, data freshness, or side effects) beyond what the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but includes a promotional second sentence about the full CRM suite, which does not help the agent select or invoke the tool. The first sentence is functional, but the second adds noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not describe the return format (e.g., list of deal objects, pagination info, total count). For a list tool, this is a significant omission. The description also lacks context on response structure or common usage patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a description. The tool description merely lists filterable fields without adding new semantic meaning or usage guidance (e.g., expected value formats, default behavior).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists/search deals, identifies the resource (deals/kanban cards), and enumerates filterable fields (query, pipeline, stage, status, owner, company, contact, tag). This distinguishes it from sibling tools like rootr_crm_get_deal (single deal) and rootr_crm_upsert_deal (create/update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for listing/searching deals but does not explicitly state when to use this vs. alternatives (e.g., rootr_crm_get_deal for a single deal, rootr_crm_list_companies for companies). No when-not-to-use or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that deletion is possible by passing `delete: true`, but the annotation `destructiveHint` is false. This is a direct contradiction: the tool can delete companies, yet annotations claim it is not destructive. Per rules, score 1 when description contradicts 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core behavior (operations) and then providing broader CRM context. Every sentence is necessary and no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the three operations and custom fields, but does not mention that `crmId` is required, that `name` is required for creation (though schema says so), or what the tool returns on success/failure. Given 13 parameters and no output schema, more completeness would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (~69-77%), but the description adds value by explaining the role of companyId, delete, and custom fields, and gives example values for size and source. However, it does not cover missing schema descriptions for `address`, `industry`, and `description` parameters, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the three operations (create, update, delete) with specific verb+resource. The title also mirrors this. It distinguishes from sibling tools like rootr_crm_upsert_contact by specifying 'company' as the target entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit conditions for each operation (omit companyId for create, pass companyId+fields for update, pass companyId+delete:true for delete). It references rootr_crm_get for custom fields. However, it does not mention when to use alternatives like rootr_crm_get for reading or rootr_crm_list_companies for listing, though the name 'upsert' implies mutation.
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=true and destructiveHint=false, so the agent knows it's a safe read. The description adds 'full detail' implying complete return data, but does not disclose any additional behavioral traits (e.g., error handling, rate limits). It adds minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states core purpose, second provides useful CRM context. No fluff or redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with one parameter and no output schema, the description sufficiently covers behavior (fetch full detail) and parameter. It lacks mention of error handling (e.g., if contact not found), but this is a minor gap for a low-complexity tool. High schema and annotation coverage compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter 'contactId' is fully described in the schema. The description mentions 'by id' in the purpose, but does not add semantic detail beyond the schema's 'Contact id'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch full detail of ONE Rootr CRM contact by id', using a specific verb and resource. It distinguishes from sibling tools like rootr_crm_get_company and rootr_crm_get_deal by focusing on 'contact'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as rootr_crm_list_contacts or rootr_crm_upsert_contact. The description omits any when-to-use or when-not-to-use information, leaving the agent to infer from context.
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=true and destructiveHint=false. The description confirms a read-only list operation but adds no new behavioral insights such as pagination details, rate limits, or response structure. It is consistent but not additive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant information. The first sentence efficiently captures the core purpose and filters, and the second provides valuable context about the CRM node. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, full schema coverage, and no output schema, the description adequately lists filterable fields and CRM context. However, it omits details on result format, pagination behavior, or sorting defaults, which would be helpful for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description reiterates the filter fields (free-text query, company, lifecycle stage, etc.) but adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as listing/searching contacts in Rootr CRM, with explicit mention of filterable fields. It differentiates from sibling tools like rootr_crm_get_contact and rootr_crm_list_companies by specifying 'contacts' within the CRM node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool is for listing contacts with filters, but does not provide explicit when-to-use scenarios or contrast with alternatives such as rootr_crm_get_contact for single contact retrieval. Usage context is implied but not detailed.
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 indicate it's neither read-only nor destructive, but the description adds minimal behavioral context beyond stating it moves a deal. It mentions optional card positioning but omits side effects (e.g., activity logging, automation triggers, return value). The description 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first describes the action and optional parameters, second gives usage guidance. It is front-loaded with key information and contains no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, prerequisites, and optional parameters. However, without an output schema, it does not explain what the tool returns (e.g., the updated deal object). This omission reduces completeness for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The description adds context like 'kanban column' and '0-based card position,' aligning with the schema. However, it doesn't provide deeper semantics beyond what the schema already offers, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Move', the resource 'deal', and the context 'to a different pipeline stage (kanban column)'. It also mentions optional parameters for cross-pipeline moves and position, distinguishing it from sibling tools like rootr_crm_update or rootr_crm_upsert_deal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'Call rootr_crm_get first to learn the target stageId/pipelineId.' While it doesn't explicitly list when not to use the tool or alternative tools, the prerequisite gives practical guidance. The tool's specific action (move deal) differentiates it from update tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses deletion capability, but annotations set destructiveHint: false, creating a contradiction. According to rules, score 1 when contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with core functionality but includes a lengthy paragraph about the CRM node that is extraneous for tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description does not clarify return values. However, it covers input semantics well for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 95%, so baseline is 3. Description adds semantics like default pipeline, status semantics, and move guidance, elevating it to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it can create, update, or delete a deal using specific verbs. It distinguishes from sibling tool rootr_crm_move_deal by advising against using it for moving stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use which operation: omit dealId to create, pass dealId to update/delete, use delete:true to delete. Also provides guidance on status changes and warns against using stageId for moves.
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=true and destructiveHint=false. The description adds value by specifying the output includes publication status and public slug/URL beyond the annotations' safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no redundant words, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description adequately conveys the purpose and implied output. It could hint at the output format, but is sufficient given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a full description for the 'target' parameter (document path or node id). The description adds no additional meaning beyond the schema, so score is at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates it checks the public status and URL of a document, using appropriate terms like 'whether' and 'at which'. It is distinct from sibling write tools like rootr_publish_document, though does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking publication status and URL, but does not provide explicit guidance on when to use this tool versus alternatives like rootr_read or rootr_publish_document.
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 readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds that it optionally filters by block, but does not disclose any additional behavioral details such as pagination or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no wasted words. It is maximally concise while conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with only two parameters and no output schema, the description is largely complete. The phrase 'Works with any key' is slightly ambiguous, but overall the description adequately covers the tool's purpose and options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning both parameters are described. The description adds 'optionally filtered to one block' which aligns with the blockId parameter, but does not add new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists comment threads on a Rootr document, with optional block filtering. It distinguishes from sibling tools like rootr_comment_document (creates comments) and rootr_comment_issue (issues).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It mentions optional block filtering and 'works with any key,' but provides no guidance on when not to use it or which sibling to choose for different tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that passing 'scene' replaces every existing shape/edge, which is destructive behavior. However, annotations have destructiveHint: false, contradicting the description. This is a serious inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise. The first sentence states the action, followed by critical usage warning, then detailed parameter guide. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, no output schema), the description covers purpose, usage, parameter details, and behavioral impact. It could mention what the response looks like, but overall it's adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context: it explains that scene replaces all content, provides an authoring guide for shapes and edges, and clarifies that text/label is indexed in knowledge graph while x/y/w/h/style are visual-only. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: merge-patch a whiteboard, updating config/icon or replacing the whole scene. It distinguishes from siblings like rootr_read_whiteboard and rootr_create_whiteboard, and provides specific verb-resource pair.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to read the board first before updating to avoid losing content, and explains when to use scene replacement. It lacks explicit 'when not to use' but provides strong contextual guidance.
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 states 'without touching other sheets', which is a behavioral guarantee beyond the annotations (readOnlyHint=false, destructiveHint=false). It clarifies the operation is additive and non-destructive. However, it does not disclose any potential side effects (e.g., sheet count limits) or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys all essential information without any redundant words. It is concise and front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, but the description does not mention what is returned (e.g., the new sheet's ID or success status). It also does not explain behavior on errors (e.g., duplicate name). For a create operation, this omission reduces completeness. The description is adequate for basic use but lacks expected output context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with descriptions (100% coverage). The description adds minimal extra meaning—only 'empty sheet' which is implicit from the context. Since the schema already explains parameters, the description does not compensate further. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a new empty sheet (tab) to an existing Rootr SPREADSHEET'. It uses a specific verb ('Add') and identifies the resource ('sheet/tab' to a spreadsheet), distinguishing it from sibling tools like 'rootr_create_spreadsheet' (whole spreadsheet) and 'rootr_delete_sheet'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to add a new empty sheet to an existing spreadsheet) but does not explicitly state when not to use or provide alternatives. For example, it does not address potential conflicts like duplicate sheet names or the difference from updating existing sheets. Usage guidance is adequate but not thorough.
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=true and destructiveHint=false, establishing safety. The description adds value by detailing the returned data (contacts, deals, activities, tasks) beyond the schema. No contradictory or missing behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first efficiently states the tool's function, the second gives CRM context. No redundancy, though the second sentence is slightly verbose for the tool alone.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, no output schema), the description sufficiently explains what is returned. It covers the primary purpose and included sub-objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'companyId' with description 'Company id'. The description does not add any additional meaning or format hints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Fetch' and the resource 'full detail of ONE company' including specific sub-resources (contacts, deals, activities, tasks). It clearly distinguishes from sibling tools like rootr_crm_list_companies or rootr_crm_get_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool versus alternatives like rootr_crm_get_contact or rootr_crm_list_deals. However, the scope is implied by listing all included related data, so usage context is somewhat clear.
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 mark the tool as readOnlyHint=true and destructiveHint=false. The description adds context about filtering, sorting, and pagination, but does not disclose any behavioral traits beyond what annotations provide. It is consistent but does not add significant new behavioral insights.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with no wasted words. The first sentence is compact and front-loaded with the core purpose. The second sentence adds context about the CRM capabilities without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has annotations and a rich input schema, it has no output schema, so the description should ideally explain the return value structure. It mentions filtering and pagination but does not describe what the output contains (e.g., list of company objects). This leaves a gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 filtering options ('optionally filtered by free-text query, owner, or tag, and sorted/paginated'), providing a concise overview that complements the individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List/search companies in a Rootr CRM, optionally filtered... sorted/paginated.' This specific verb+resource combination distinguishes it from sibling tools like rootr_crm_list_contacts or rootr_crm_list_deals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for companies within a CRM node, but it does not explicitly state when to use this tool vs alternatives (e.g., rootr_crm_list_contacts for contacts) or when not to use it. The usage is implied but not explicit.
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 a non-destructive mutation. The description adds that a new token is issued, but does not detail side effects (e.g., whether multiple links can exist or if old links are invalidated). With annotations covering safety, the description provides adequate but minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and includes a necessary cross-reference to rootr_update_form. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with one parameter and no output schema, the description covers the purpose and links to a related tool. It omits explicit mention of the return value (the link/token), but the agent can infer it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with formId described as 'FORM node id'. The description does not add parameter-level details beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool issues a new public share link for a Rootr form to allow external submission, with specific verb (issue) and resource (share link/token). It distinguishes from sibling rootr_list_form_share_links by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that the tool is for creating a link after the form's public-submit mode is configured via rootr_update_form. This implicitly guides when to use it, though it lacks explicit 'when not to use' or comparison with alternatives like rootr_list_form_share_links.
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 readOnlyHint=false and destructiveHint=false. The description adds context about field types but does not disclose other behavioral traits like side effects or permissions. It 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences front-loading the main purpose, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's function, field specification, and subsequent steps. However, it does not mention the return value or prerequisites like workspace existence. Given the absence of an output schema, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description reiterates some schema info but adds minor detail about relation fields. No significant new semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a typed LOG store, a structured table-like node. It specifies field types and distinguishes from related tools like rootr_add_log_entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs the agent to use rootr_add_log_entries afterward and rootr_query_log_entries/rootr_log_stats for reading. It provides clear context but lacks explicit when-not or alternatives to other create 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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds context about being part of a CRM node and auto-linking, but doesn't disclose additional behaviors like pagination details or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence covers purpose and filters efficiently. The second sentence provides extra CRM context, though it is somewhat verbose with parentheticals. Still, it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description doesn't explain what the response contains (e.g., task fields). It covers input filters well but omits pagination behavior and output structure. Given the tool's complexity (9 params), it is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 56%, the description helps by listing filterable dimensions (status, assignee, due, contact, company, deal), which adds context for parameters without descriptions (e.g., assigneeId, companyId). However, it doesn't detail syntax or formats beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (follow-up tasks in Rootr CRM), and lists specific filterable fields, distinguishing it from sibling tools like rootr_crm_list_deals or rootr_crm_list_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides what filters can be applied, giving context on when to use. However, it doesn't explicitly mention when not to use or compare to alternatives like rootr_crm_list_activities, but the purpose is clear enough for a list operation.
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 (readOnlyHint=false, destructiveHint=false) indicate a non-read, non-destructive mutation. The description adds that it performs a deep copy and returns the new node, but does not detail side effects, permission requirements, or limit constraints. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no filler, and front-loads the core purpose. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema, the description adequately explains input and return value. It could mention the structure of the returned node, but overall it is sufficiently 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-defined. The description reiterates the purpose of 'targetWorkspaceId' and the deep copy behavior, but adds no new semantic meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deep-copies a Rootr node (document or folder tree) to the same location or a different workspace. 'Duplicate' in the name and 'deep-copy' in the description make the purpose unambiguous. Among siblings, no other duplication tool exists, so it is well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for duplicating nodes, mentioning 'next to the original' or 'into another workspace', but lacks explicit guidance on when to use versus alternatives or prerequisites like user permissions. However, the tool name and uniqueness among siblings make the context clear enough for selection.
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=true and destructiveHint=false, so the safety profile is clear. The description adds 'full details' but doesn't elaborate beyond that, providing minor additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficiently stating the purpose with no unnecessary words. Front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one parameter, no output schema), the description provides adequate information. However, it could have elaborated on what 'full details' includes, but not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds no extra meaning beyond 'by id', which is already implied by the required parameter issueId in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Fetch', the resource 'issue', and the scope 'by id', clearly distinguishing it from sibling tools like rootr_list_issues and rootr_update_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: use when you have an issue id and need full details. No explicit alternatives or exclusions, but the context is clear for a simple read operation.
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 readOnlyHint annotation, the description discloses that secrets are not re-shown, which is a key behavioral trait for this tool. It does not contradict the annotations (readOnlyHint=true is consistent).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: one for purpose, one for important behavioral note. No wasted words, front-loaded, and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the response structure (e.g., list of webhooks with properties). It only mentions secrets not being shown. Missing details like pagination, ordering, or typical fields (ID, URL, events) leave the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the workspace parameter and its default. The description adds no additional parameter meaning, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists webhooks on a workspace, using a specific verb and resource. It distinguishes from sibling tools like create and delete, and adds valuable context about secrets not being returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use (to list webhooks) and explicitly warns that secrets are not re-shown, guiding the agent to look elsewhere for secrets. It lacks explicit when-not-to-use or alternative tool names.
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 context about grouping and metrics, but annotations already declare readOnlyHint=true and destructiveHint=false, so the description's behavioral insight is limited. It does not cover rate limits, authentication, or data volume effects, but the annotations mitigate the need. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first delivers the core functionality, the second adds usage guidance. No fluff, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the clear purpose, the description omits the return format (e.g., structure of aggregated results). Without an output schema, an agent needs to know what the response looks like to parse it. This is a significant gap for a grouping + metrics tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already described. The description adds value by explicitly listing the valid values for groupBy (hour/day/source/level) and metric (count/avg/max/min/sum), which are not fully captured in the schema (groupBy is just 'string' with no enum). This extra detail helps the agent choose correct values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes aggregate statistics over LOG entries, lists valid group-by options and metrics, and distinguishes from pulling raw entries. It uses a specific verb (Compute) and resource (aggregate stats over LOG store), and effectively differentiates from siblings like rootr_query_log_entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that it is 'useful for trend/volume questions without pulling raw entries,' implying an alternative use case. However, it does not name the specific sibling tool (e.g., rootr_query_log_entries) for raw data retrieval, which would strengthen guidance.
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 provide readOnlyHint=true and destructiveHint=false, so the read-only nature is clear. The description adds no additional behavioral details (e.g., pagination, rate limits, response format). It is adequate but relies on annotations for safety 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant words. First sentence states the purpose and filters; second sentence provides usage guidance. Perfectly concise and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary use case and provides a logical next-step (rootr_ask). While it lacks explicit return value information (no output schema), the purpose and filters are well-described. For a read-only query tool with many parameters, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented. The description mentions key filters (time range, source, level, anomaly flag) but does not add meaning beyond what the schema provides. For a high-coverage schema, the description offers minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries/filters log entries by specific criteria (time range, source, level, anomaly flag). It distinguishes itself from sibling rootr_ask by positioning itself as a preliminary inspection step. The verb 'query/filter' plus resource 'LOG store' makes the purpose precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides when to use this tool: 'inspect recent activity or find anomalous entries' and recommends it before using rootr_ask for analysis. This provides clear context, though it does not mention other possible alternative tools like rootr_read or rootr_search, which could handle similar tasks.
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 readOnlyHint=false and destructiveHint=false. The description adds context about authentication tokens but does not detail side effects or behavior when the document is not published.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The essential information is front-loaded: action, resource, example, and authorization constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation with two parameters, the description covers purpose, usage, and authorization. However, absence of output schema means no return value description, but this is acceptable for a tool that likely returns a confirmation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds value by providing an example usage ('{"isPublic": false} to unpublish'), but this only slightly enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'public settings of a Rootr (루터) document', with an example. It distinguishes from siblings like 'rootr_publish_document' and 'rootr_document_public_status' by focusing on modifying existing settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies authorization requirements (owner-level, account key) and mentions token restrictions. It implicitly guides use when having proper credentials but does not explicitly list when to use 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?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description adds moderate value by detailing the closing behavior. However, it does not clarify whether the update is a partial patch or a full replacement, nor does it discuss side effects or auth requirements 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states general purpose, the second provides essential closing specifics. No redundant text; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters (1 required) and no output schema, the description covers core functionality and a key use case (closing). It does not describe the return format or patch semantics, but annotations partially compensate for safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the description reinforces schema details for state and stateReason (closing guidance). It adds no additional meaning beyond the schema for most parameters, so it meets the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Update an issue' and description 'Update arbitrary fields of a Rootr (루터) issue' clearly specify the action (update) and resource (issue). The description also distinguishes it from sibling tools like rootr_create_issue, rootr_get_issue, etc., by explicitly stating it modifies existing issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific guideline for closing an issue (set state to CLOSED and stateReason accordingly). However, it lacks explicit instructions on when not to use this tool versus alternatives like rootr_create_issue or rootr_get_issue.
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 a write operation (readOnlyHint: false, destructiveHint: false). The description adds no further behavioral traits beyond confirming the creation action, which is consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy. The main action is front-loaded, and each sentence serves a purpose (action statement, parameter explanation, nesting hint).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the creation action and key parameters but omits return value behavior. With no output schema, the agent might benefit from knowing the created object's structure. Still, it's sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds valuable context: labels are label ids, type is a type id from tracker definitions, and parentIssueId creates a sub-issue. This enhances understanding beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new issue') and the specific resource ('Rootr issue tracker'). It is distinct from sibling tools like rootr_get_issue, rootr_list_issues, and rootr_update_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to create issues) and provides guidance on parameter values, referencing rootr_read for definitions. It lacks explicit when-not or alternative tool references, 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. Description adds filtering options but does not disclose pagination, default result size, or return format. With annotations covering the safety profile, the description adds moderate value but lacks richer behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. The most critical information (what the tool does and when to use alternative) is front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description does not mention what fields are returned or any limits. For a list operation, expected return format (e.g., issue IDs, titles) is omitted. Adequate but could be more complete by hinting at the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. Description mentions filtering by state, label, type, and query, which rephrases schema info without adding new semantic meaning. Baseline 3 is appropriate as schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'list', the resource 'issues in a Rootr issue tracker', and the optional filters. Explicitly distinguishes from sibling tool rootr_get_issue by noting that tool is for full details of one issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context (list with filters) and an alternative 'use rootr_get_issue for full details of one issue', guiding the agent away from this tool for single-issue detail 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 declare readOnlyHint=true and destructiveHint=false, signaling a safe read-only operation. The description adds that it is a full-text search and returns documents, but does not disclose potential limitations such as pagination, indexing delays, or scope constraints. With annotations covering the safety profile, the description provides moderate added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences. It immediately communicates the core function and intended usage. Every word earns its place, and the critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter, full schema coverage, and clear annotations, the description is complete. It explains the purpose, when to use it, and the basic nature of the search. No output schema is needed, and all necessary context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'query' already has a description ('Search query text'). The description's mention of 'full-text search' implicitly suggests the query is free text, but it does not add significant meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a full-text search across the connected Rootr workspace, using a specific verb and resource. It distinguishes itself from sibling tools by positioning itself as a discovery tool to find documents before reading or editing, which is unique among the listed 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by saying 'Use this to find relevant documents before reading or editing them.' This implies when to use the tool but does not explicitly mention when not to use it or suggest alternatives like 'rootr_ask' for Q&A. The guidance is helpful but lacks 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?
Annotations indicate readOnlyHint=false (write) and destructiveHint=false (non-destructive), which the description matches by stating 'append' and 'additive.' The description adds behavioral context by specifying that entries are shaped per the store's field schema, going 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are compact and front-loaded: first sentence describes the core action, second clarifies additive nature and field schema. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description covers purpose, additive behavior, and entry structure. It doesn't explain how to obtain logId or return values, but these are assumed from context. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds context that entries carry optional fields like ts, source, level, message, data and that they conform to the store's field schema, providing semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool appends entries to a LOG store, listing the possible fields (ts, source, level, message, data) and calling it additive. It distinguishes from siblings like rootr_query_log_entries (query) and rootr_create_log_store (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'append one or more entries' and 'additive — existing entries are untouched,' implying use for writing log data. It does not explicitly state when to use versus alternatives like rootr_add_row or rootr_query_log_entries, but the sibling list provides some implicit guidance.
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 show readOnlyHint=true and destructiveHint=false. The description extends this by noting the return format (answer text plus citations) and the scope requirement, adding useful behavioral context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, usage context, requirements and return. No fluff, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return format, scope, and usage context. Missing details like rate limits or error handling, but these are minor for a read-only query tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The description adds no new semantic information beyond what the schema provides; the workspace default is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool asks natural-language questions against the Rootr knowledge graph, specifically for root-cause-analysis across linked documents and log anomalies. It distinguishes from sibling tools like rootr_search (single document) by emphasizing cross-document reasoning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: good for RCA questions needing reasoning across linked documents and log anomalies, rather than a single document. It mentions the required `ask` scope but does not explicitly state when not to use it or name alternative tools.
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 show readOnlyHint=false, destructiveHint=false, aligning with a non-destructive write operation. The description adds context about user identity and auth, going beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the core purpose, second provides critical auth guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with no output schema, the description covers purpose, auth, and context. It is sufficient to differentiate from sibling tools and guide correct usage, though it could mention expected return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all three parameters described. The description adds minimal value beyond schema, but it links trackerId and issueId contextually. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add a comment to a Rootr (루터) issue within its tracker.' This clearly specifies the verb (add), resource (comment), and context (issue in tracker). It distinguishes from sibling tools like rootr_comment_document and rootr_create_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the authentication requirement: an ACCOUNT key (PAT) is needed, not a workspace key, which would get a 403. This tells when to use and what not to use, though it does not explicitly mention alternative tools for other operations.
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 the tracker with its id and default labels/types, and implies a creation (non-destructive) behavior consistent with annotations. No contradictions. Could be enhanced by noting permission requirements or side effects, but adequate given the simple nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, with the primary action and purpose front-loaded. Every sentence adds value: the first states the action and type, the second clarifies the return and next step. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is mostly complete. It explains what the tool creates, what it returns (id + defaults), and how to proceed. Lacks specification of return format details, but sufficient for a straightforward creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already fully describes both parameters (name and workspace, including default behavior). The tool description adds no additional parameter-level details beyond what the schema provides, so a 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('issue tracker document'), describes it as 'GitHub-style', and explicitly distinguishes from the sibling tool 'rootr_create_issue' by noting that issues are added afterward. This provides excellent purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear next-step usage hint ('use rootr_create_issue afterward to add issues to it'), which helps the agent understand the workflow. However, it does not mention when not to use this tool or list explicit prerequisites beyond the workspace parameter default.
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 indicate non-readOnly and non-destructive. The description adds that it is a bulk import operation and auto-links into the knowledge graph. However, it does not disclose details like whether duplicates are handled, error behavior on partial failures, or any required permissions beyond the CRM context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, usage context, and parameter hints. No unnecessary words, well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality, parameter semantics, and a key behavioral point (auto-linking). It lacks details on return values (e.g., count of imported rows, error handling), which are important for a bulk import tool. Given no output schema, more information on expected response would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds value by explaining that the 'rows' array must match the create shape of the chosen entity (referencing rootr_crm_upsert_* tools), and clarifies the 'entity' parameter options. This goes beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool bulk-imports rows into a Rootr CRM as companies, contacts, or deals in one call, using the 'entity' parameter. It distinguishes from sibling upsert tools by explicitly mentioning it's an alternative to calling those one row at a time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use this tool: for migrating a spreadsheet/CSV of leads or accounts instead of using upsert tools individually. It mentions the entity parameter and refers to the create shapes of sibling tools for row format, providing actionable guidance. It does not explicitly list when not to use, but the context is sufficient.
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 readOnlyHint=false and destructiveHint=false. The description adds that passing pipelines replaces the entire array, a non-obvious behavioral trait. However, it does not clarify whether other fields (config, fields, icon) are also replaced or merged, leaving some ambiguity. The merge-patch term implies partial update for those fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence directly stating the action. The second sentence includes extra context about the CRM feature set, which is useful but somewhat verbose. Overall, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the replacement behavior for pipelines and recommends prior retrieval, which is good. However, it does not describe the return value (no output schema), nor does it clarify whether other fields are merged or replaced. The tool has nested objects and complex behavior, so more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters have descriptions). The description adds context about merge-patch behavior and the replacement effect for pipelines, but does not provide additional per-parameter details beyond what the schema already offers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (merge-patch) and resource (Rootr CRM node), and specifies which parts can be updated (pipelines, fields, config, icon). It distinguishes the tool from siblings by focusing on updating an existing CRM node, contrasting with creation or retrieval 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: for updating a CRM node. Provides critical guidance: passing 'pipelines' replaces the whole array, so users should call rootr_crm_get first to preserve existing stages/pipelines. This clarifies when not to use the tool directly without preparation.
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 destructiveHint and readOnlyHint. The description adds value by clarifying that deletion is recoverable (trash), not permanent. This is important behavioral context that annotations don't capture, but it doesn't mention other traits like permissions or side effects on child items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and key behavioral info. Every word is necessary, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool with annotations, the description covers the main points: action, recoverability, and usage guidance. It lacks details about what happens to folder contents or return value, but these are minor omissions given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description in the schema is already clear (path or node id). The description adds no additional parameter-level information, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes Rootr documents/folders by moving to trash, and the name/title reinforce this. While it doesn't explicitly differentiate from siblings, the resource type (node) is distinct from row, webhook, sheet deletions, so purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using rootr_read/rootr_list first to confirm the target, which is good practice for a deletion tool. However, it doesn't specify when not to use it (e.g., for permanent deletion) and doesn't mention any prerequisites like permissions.
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 behavioral context beyond annotations by stating irreversibility. Annotations already indicate destructiveHint=true, so the description reinforces this with a clear warning, though no additional side effects are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: the first states the core action, the second adds crucial caution. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two parameters and no output schema, the description is largely complete. It could potentially mention error behavior (e.g., if webhook not found), but this is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema provides descriptions for both parameters. The tool description does not add any additional meaning beyond what the schema already offers, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (webhook), and the context (Rootr workspace). It distinguishes itself from sibling tools like rootr_list_webhooks and rootr_create_webhook by specifying deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly specify when to use this tool, but the irreversible nature ('cannot be undone') serves as a strong caution. Given the simplicity and lack of alternative delete mechanisms for webhooks, this is adequate.
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 readOnlyHint=true and destructiveHint=false, so the tool is clearly safe. The description adds behavioral context by noting the return order ('most recent first') and the general listing behavior, going beyond the annotations. It does not cover edge cases (e.g., missing document) but is adequate given the simple read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that fully convey the action, ordering, and use case. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality, return order, and purpose, which is sufficient for a simple list tool with good annotations and a clear parameter schema. However, it does not mention what happens when there are no versions or the target is invalid, and the lack of an output schema means the return format is entirely unspecified, leaving a slight gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for both parameters (limit and target), each with clear descriptions. The tool description does not add any additional meaning beyond the schema, so it meets the baseline of 3 without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List saved versions of a Rootr (루터) document, most recent first.' This specific verb and resource combination distinguishes it from sibling tools like rootr_read or rootr_edit, and the additional context about seeing changes and recovering revisions reinforces its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's utility ('useful for seeing what changed and when, or to recover an older revision'), providing clear context for when to use it. However, it does not explicitly mention when not to use it or point to alternatives among the many sibling tools, missing a chance to fully differentiate.
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=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by explaining the returned data structure (sheets with sparse cells map and dimensions), which is valuable 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with no wasted words. The first sentence defines the core functionality, and the second provides immediate context on when to use it. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately explains the purpose, input, and output shape (sheets with sparse cells and dimensions). It lacks details on the cells map structure, but for a read tool with good annotations, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage and only one parameter ('spreadsheetId' described as 'SPREADSHEET node id'), the description adds no additional meaning. The baseline of 3 is appropriate as the schema already fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read a Rootr SPREADSHEET node' with specific verb and resource. It mentions the output structure (sheets with sparse cells map and dimensions), distinguishing it from sibling tools by noting it should be called before update/patch operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to call this tool ('before rootr_update_spreadsheet / rootr_patch_spreadsheet_cells'), providing clear usage context. However, it does not mention when not to use it or offer explicit alternatives for different tasks, missing the highest tier.
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 annotations indicate a non-destructive mutation (readOnlyHint=false, destructiveHint=false). The description adds that it reorders slides, which is consistent but does not disclose further behavioral traits like permissions needed or error handling. The additional detail about requiring a full list adds some value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the main usage, it omits what the tool returns (no output schema) and does not address error cases or permissions. Given the tool's mutation nature, additional context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes parameters, but the description adds crucial context: 'order must be the FULL list of the deck's slide ids, in the new desired order' and advises to read the presentation first. This significantly clarifies the parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reorder') and the resource ('slides of a Rootr presentation'). It distinguishes from sibling tools like rootr_update_presentation_slide and rootr_append_presentation_slides, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call rootr_read_presentation first to get current slide ids, providing clear context for correct usage. However, it does not mention when not to use this tool or alternative approaches.
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 indicate readOnlyHint=false (write operation) and destructiveHint=false (non-destructive). The description adds authentication context and that it's not anonymous, but does not disclose side effects like data creation or potential overwrites. Behavior is adequately described for common cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose and immediate parameter guidance. No superfluous content; every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the essential input behavior and prerequisite. It could mention the result of submission, but with sibling tools like rootr_list_form_responses, the context is sufficiently complete for a submission tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds value by explaining that 'values' is keyed by field id and advising to read the form first to get exact ids, enhancing understanding beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (submit one response), the resource (Rootr form), and distinguishes it from the public anonymous flow, making it specific 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear prerequisite (call rootr_read_form first) and implies the tool is for authenticated submissions. Does not explicitly list alternatives or conditions when not to use, but offers sufficient guidance for typical usage.
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 non-readonly and non-destructive. The description adds that the CRM node is auto-linked into the knowledge graph, providing behavioral context beyond annotations. It 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states the core function, the second elaborates on optional features. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain return values or output, which is a gap given there is no output schema. For a complex creation tool, return info would be helpful. Otherwise, it covers the input side well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning by explaining high-level intent (seeding pipelines, fields with sane defaults) and clarifying that stages have probability/color, which aids understanding of nested objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new CRM node with companies, contacts, multi-pipeline deals, activities, and tasks. It distinguishes from sibling tools like rootr_crm_update or rootr_crm_get by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that custom pipelines and fields are optional with sane defaults, effectively telling when to use these parameters. However, it lacks explicit guidance on when not to use this tool or alternatives, which is partially mitigated by sibling 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?
Annotations have readOnlyHint=false and destructiveHint=false. The description discloses that the tool can delete (via delete parameter), auto-link contacts to companies, and that leadScore is computed automatically. This adds behavioral context beyond annotations, though it does not detail rate limits or auth needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a contextual note about Rootr CRM. It is front-loaded with key instructions and is reasonably concise, though the CRM context sentence could be shortened without losing essential meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, 80% schema coverage, and no output schema, the description covers the main behaviors (CRUD operations, auto-linking, leadScore) and provides context about being part of a CRM node. It does not describe return values, but that is expected without an output schema. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% (most parameters have descriptions). The description adds meaning by explaining that omitting contactId creates, including contactId updates, and delete:true deletes. It also clarifies that leadScore is server-side computed and email auto-links to company. This supplements the schema well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool can create, update, or delete a contact based on parameters (omit contactId for create, include contactId for update, add delete:true for deletion). It also explains auto-linking and server-side leadScore computation, distinguishing it from sibling list/get 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use each operation (create vs update vs delete) and mentions that email auto-links to company and leadScore is computed server-side (so do not set it). However, it does not compare directly with sibling tools like rootr_crm_upsert_company, but the guidance is sufficient for this tool's internal logic.
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=false, destructiveHint=false) indicate mutation but not destruction. The description adds context about linking to contacts/companies/deals and knowledge graph auto-linking. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. Front-loaded with core action. Excellent economy of words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core usage and context, but omits return value and error handling. Given no output schema, some missing info. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the crucial taskId parameter's role and provides an example. With 70% schema coverage, it adds meaning beyond schema for the upsert behavior, though not all parameters are addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates follow-up tasks, specifying the upsert pattern. It distinguishes from sibling CRM upsert tools (company, contact, deal) by focusing on tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to include taskId (update) vs omit (create) and gives an example of setting status to done. However, it does not explicitly compare to other tools like list_tasks or log_activity, leaving some ambiguity.
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 set destructiveHint=true, but the description adds valuable context: it deletes exactly one row, and any linked page is moved to the trash (not permanently deleted). This goes beyond the annotation by explaining the side effect, aiding the agent in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the core action and a key side effect; the second provides a critical safety instruction. It is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description covers the essential: what is deleted (one row), how to identify it (rowId, databaseId), and what happens to linked content (moved to trash). It also includes a usage caution. No output schema is needed for a delete tool, so the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-described in the schema. The description adds no additional semantic detail about the parameters beyond mentioning rowId and database by name. The side effect about linked pages is behavioral, not parameter-specific. This meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and identifies the resource as 'ONE row of a Rootr DATABASE'. It distinguishes from siblings like rootr_add_row or rootr_update_row by specifying the action is deletion and mentions the side effect of moving linked pages to trash, which is unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Verify the row via rootr_read_database first — do not guess rowIds', providing clear when-to-use guidance and a caution. While it does not explicitly list when not to use, the instruction implies the tool should only be used after verification, and the sibling set makes the distinction 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 declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral details: the response structure (values keyed by field id) and ordering. It does not contradict annotations and provides context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences that front-load the main action and key details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description is complete. It explains the output content, ordering, and provides a usage pattern (calling rootr_read_form first).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter formId with a brief description. The description adds no additional semantic information beyond what is in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (List), the resource (form responses), and ordering (most recent first). It distinguishes itself from siblings like rootr_read_form (which reads form structure) and rootr_submit_form_response (which submits responses).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call rootr_read_form first to map field ids to names, providing clear context for use. It does not include explicit exclusions or alternatives, but the guidance is sufficient for the tool's simplicity.
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=true and destructiveHint=false. The description adds context that the tool lists 'existing' links, reinforcing the read-only trait. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, directly phrased sentence that conveys all necessary information with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is complete enough to understand its purpose and required input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the formId parameter clearly described. The description does not add extra meaning beyond what the schema provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the verb (List), the resource (public share links/tokens), and the scope (for a Rootr FORM). It distinguishes from sibling tool rootr_create_form_share_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing existing share links but does not explicitly state when to use or when not to use alternatives. However, the contrast with rootr_create_form_share_link provides 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?
Annotations are minimal (readOnlyHint false, destructiveHint false). The description adds that it creates multiple nodes, requires docs:write scope, and expects real building blocks. It doesn't detail idempotency or failure modes but provides adequate context for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than necessary, including workflow instructions (precondition, after creating) that could be in a separate workflow guide. However, the main purpose is front-loaded and each sentence adds value, so it's still functional but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description omits return value details. It covers prerequisites and next steps well, but missing information on what the tool returns or error conditions leaves some gaps. Sufficient for an experienced agent but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds value by explaining the tree as 'real building blocks with icons/views/seed content' and referencing llms.txt for the schema. It clarifies rootPath and workspace defaults effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a document tree inside an existing Rootr workspace, with optional root path. This distinguishes it from siblings like rootr_scaffold_plan (planning) and rootr_create_workspace (workspace creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides preconditions (call rootr_scaffold_plan first, ask clarifying questions, design tree) and post-conditions (offer webhook). This guides the agent on when and how to use the tool versus alternatives.
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 readOnlyHint false and destructiveHint false. Description adds important behavioral context about authentication key requirements and error handling, going 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no unnecessary words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key behavioral aspects (auth, fallback), but lacks return value description. No output schema, so some completeness gap exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions optional block anchoring and reply, but this is already in param descriptions. No significant new parameter insight beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Add a comment', the resource 'Rootr document', and optional features 'anchored to a block, or as a reply via parentId'. It distinguishes from sibling tools like rootr_comment_issue and rootr_append.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (requires ACCOUNT key) and when to fall back to rootr_append (workspace key gets 403). Provides clear authentication 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?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds valuable context: defaults to a single empty 'Sheet1', cell addressing details, and the effect of setting a cell to null. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary action and is well-structured. Each sentence conveys necessary information without redundancy. Slightly long but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (0 required) and no output schema, the description does not mention what the tool returns (e.g., created node). It provides good workflow context (recommending read first), but the lack of return information is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning: explains the default when 'data' is omitted, describes the cell address format and sparse map structure, and clarifies how to clear cells. This enriches understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new SPREADSHEET node' with a specific verb and resource. It distinguishes from DATABASE, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use this tool ('when content needs calculation') and when to use an alternative ('for plain tracked lists use DATABASE instead'). Also recommends reading the sheet first before patching.
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 readOnlyHint false and destructiveHint false. Description adds that activities are 'auto-linked into the knowledge graph', which is valuable behavioral context beyond annotations. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loading the core action. Every clause serves a purpose: activity types, attachment targets, usage context, and CRM background. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 8 params (2 required) and no output schema, the description covers purpose, usage, and key attachments. Missing details on return value or error cases, but acceptable given tool type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (4/8 params described). Description clarifies that activities attach to contact/company/deal and that occurredAt defaults to now if omitted, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Definition states 'Log an activity (note|call|email|meeting) on a Rootr CRM's timeline' with explicit attachment to contact/company/deal. Clearly distinguishes from sibling tools like rootr_crm_list_activities (listing) and rootr_crm_upsert_task (tasks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Says 'Use this to record outreach/history that shows up on the detail view', providing clear context. However, it does not explicitly state when not to use it or contrast with alternatives like task logging.
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 it is not read-only and not destructive. The description adds that it consumes AI credits and stores images as workspace attachments, providing helpful behavioral context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly long but well-structured, front-loading the primary action and usage context. Each sentence adds value, though it could be trimmed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return value structure, how to use the result in slide images, and prompt tips. It lacks mention of error conditions or file size limits, but for basic usage it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the schema (100% coverage). The description adds valuable tips for the `prompt` parameter (e.g., clean, flat illustration, colors, no text) and explains the role of `nodeId` (permission-checked) and `workspace` (default behavior).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an image from a text prompt using AI, stores it as a workspace attachment, and returns a URL for use in slides. It distinguishes itself from the sibling tool `rootr_remove_image_background` by focusing on generation for presentation visuals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when building a Rootr presentation' and provides detailed prompt tips (e.g., 'no text', specify colors). It does not explicitly exclude alternative uses, but the context is sufficiently 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that the operation is on the connected workspace and optionally filtered by path prefix, which is useful context. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, optional filter, and usage recommendation. Every word is meaningful and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of a list tool with one optional parameter and no output schema, the description covers the essential context: workspace scope, path filter, and its role as a discovery step. It does not detail output format or pagination, but that is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'path'. The description adds an example ('e.g. "/notes"') that provides more concrete guidance beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'documents and folders' in the 'connected Rootr workspace', with an optional path prefix filter. It distinguishes from sibling operations like rootr_read or rootr_list_rows by specifying it's for discovering existing items before further actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool first to discover what exists before reading or writing, which provides clear guidance. However, it does not mention specific alternatives or when not to use it, which would be helpful given the many sibling list tools.
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=true and destructiveHint=false, indicating safe read-only behavior. The description adds value by detailing the output content (id, values, position) and what is omitted (schema). However, it does not mention potential pagination, ordering, or limits, which would enhance transparency further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the core action and output, while the second provides usage guidance. No wasted words, front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no output schema, and annotations present, the description covers the tool's purpose, return content, and alternative tool guidance. It is reasonably complete, though it could mention any default behavior like ordering or all rows returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'databaseId' described as 'DATABASE node id'. The description does not add further meaning, such as format or constraints, beyond the schema. With high coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'list', the resource 'rows of a Rootr DATABASE', and explicitly states what is included (id, values, position) and excluded (schema). It also distinguishes from the sibling rootr_read_database, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly tells when to use this tool versus the alternative rootr_read_database: 'Use rootr_read_database instead when you also need the property/column definitions.' This provides clear context for appropriate usage.
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 mark the tool as read-only and non-destructive, so the description does not need to restate these. The description adds value by specifying the exact data returned (shapes and edges), which helps the agent understand the tool's behavior 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both essential. The first clearly states the tool's action and output, while the second provides critical usage guidance. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, clear annotations), the description covers the core aspects: what it reads, what it returns, and when to use it. It could optionally mention that the output is a JSON object, but it is not strictly necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter whiteboardId; the description does not add new parameter-level details beyond what the schema provides. Therefore, it meets the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Read' and identifies the resource as a 'WHITEBOARD node'. It clarifies the return structure by mentioning 'full scene (shapes[] and edges[])', and implicitly distinguishes from sibling tools like rootr_update_whiteboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this tool before rootr_update_whiteboard to obtain current shape/edge ids and content, providing clear and actionable usage 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?
Annotations indicate it is not read-only and not destructive. The description adds that the result is a new transparent PNG and returns { id, url, ... } for placement on a slide. It explains the non-destructive nature (creates new, doesn't modify original) but does not mention limitations like file size or processing time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: action, input/output, and usage context. Every sentence adds value without redundancy, achieving high conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description covers the main workflow, use case, and expected return format. It lacks mention of error conditions or edge cases (e.g., non-background images), but overall it is complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions. The description adds context by specifying that the source attachment id comes from rootr_generate_image or an upload, and implies the nodeId is needed to attach the result to a presentation, enriching the schema's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove the background' applied to 'an existing Rootr workspace attachment', and specifies the output as 'a new transparent PNG'. This distinguishes it from sibling tools like rootr_generate_image that create images rather than process them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool: 'for product shots / logos / subjects that should sit on the slide without a boxed background.' It also mentions that the source attachment id comes from rootr_generate_image or an upload, but does not explicitly say when not to use or list alternatives.
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 annotations (readOnlyHint=false, destructiveHint=false), description details partial patch behavior, null clearing, and position reordering. Adds context for kanban card movement. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a note. Front-loaded with core action. Every sentence adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main usage: patch semantics, clearing, position, and kanban move. Mentions getting rowIds. Lacks error handling or return value description (no output schema). Adequate for a patch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds clarity to 'values' (maps name or id, only passed keys change, null clears) and 'position' (0-based reordering). Provides nuance beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('merge-patch ONE row'), the resource ('a Rootr DATABASE'), and identification method ('by rowId from rootr_read_database'). It distinguishes from siblings like rootr_add_row and rootr_read_database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use: for updating a row with specific patch semantics. Includes special case for moving kanban cards. However, does not explicitly contrast with other update tools 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description emphasizes that cells are not touched, which is critical for a mutation tool with destructiveHint=false. Adds value beyond annotations by clarifying the scope of the update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Front-loaded with action and scope. Efficient and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 8 parameters and no output schema, the description covers purpose and prerequisite. Missing details like error conditions or concurrency, but acceptable given the tool's specificity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description hints at key parameters (name, dimensions, row-col sizing) which align with schema properties. Schema already covers 75% of parameters; description adds context but does not detail each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool performs a merge-patch on a single sheet's name, dimensions, and row-col sizing by sheetId, without affecting cells. Distinguishes from sibling tools like rootr_update_spreadsheet and rootr_patch_spreadsheet_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call rootr_read_spreadsheet first to obtain the exact sheetId. Does not provide exclusions or alternatives, but the context makes the usage 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 destructiveHint=true and readOnlyHint=false. The description reinforces destructive nature and explains concurrency guard via etag, adding valuable behavioral context 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with primary action. Every sentence is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers destructive behavior, concurrency protection, and alternative tools. No output schema, but return value info is minimal; overall complete for usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters (target, content, ifMatch). The description references ifMatch in context but does not add new parameter-level details beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (replace entire content or create new document) and resource (Rootr document), and distinguishes from siblings by naming rootr_append and rootr_edit for incremental 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: read the document first and use etag as ifMatch to avoid clobbering concurrent changes. Also directs to prefer siblings for incremental changes.
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 the write nature (consistent with readOnlyHint=false) and provides detailed value shape rules for various types. Lacks error handling or auth details, but annotations already cover safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, every sentence adds unique value. No redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers parameter semantics and usage guidance well. Missing return value description (output schema absent) and error scenarios, but overall comprehensive for a create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant value beyond schema by explaining value shapes per type (e.g., date format, select option name). The schema has 100% coverage but description deepens understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Append a row') and the resource ('Rootr DATABASE'). It provides specific details about how to map values, distinguishing it from sibling tools like rootr_update_row.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises calling rootr_read_database first to learn columns, providing clear prerequisite guidance. Doesn't explicitly state when not to use, but the context of adding a row 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 adds critical context beyond annotations: 'Not recoverable' and suggests pre-deletion verification. annotations already indicate destructiveness, but the description enhances user awareness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with no extraneous words. It front-loades the action and necessary precautions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter destructive tool with no output schema, the description covers purpose, behavior (irreversibility), and a cautionary note. No further details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with adequate descriptions for both parameters ('Sheet id to delete' and 'SPREADSHEET node id'). The description adds no extra parameter meaning, meeting the baseline for comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Delete one sheet (tab) from a Rootr spreadsheet by sheetId,' providing a clear verb-resource pairing. It distinguishes this tool from siblings like rootr_delete_node, rootr_delete_row, and rootr_create_sheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'read first to confirm,' implying a cautionary usage context for a destructive operation. However, it does not explicitly compare to alternatives like update_sheet or specify non-deletion 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 indicate non-read-only and non-destructive, but description adds crucial details: sparse patch (only touches keys sent), setting null clears cells, and formulas are recalculated server-side. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is appropriately sized (~100 words) and front-loaded with key purpose. Could be slightly more concise but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers preconditions (read first), behavior (sparse patch, null clearing), and usage guidance. Comprehensive for a patching tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining A1-style addressing, the sparse map format with examples, and the null clearing behavior, which enriches understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Sparse-patch cells of ONE sheet' with specific verb and resource, and distinguishes from sibling 'rootr_update_spreadsheet' by stating preference when only editing cell values/formulas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'PREFER this over rootr_update_spreadsheet when you are only filling in / editing cell values or formulas' and advises reading the sheet first via 'rootr_read_spreadsheet' to know dimensions and content.
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 readOnly and non-destructive. Description adds behavioral details: returns schema and rows, works only on DATABASE nodes, and mentions select column context for board/kanban views.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first states the core purpose and outputs; the second provides key usage guidance and constraints. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with one parameter and no output schema, the description fully explains return structure (schema + rows) and usage prerequisites, making it 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. Description does not add new semantic details beyond what's in the schema description ('DATABASE node id'), so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read a Rootr DATABASE node' and specifies the exact outputs: schema and all rows. It distinguishes from sibling tools by focusing on DATABASE nodes and contrasting with add/update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'ALWAYS call this before rootr_add_row / rootr_update_row' and restricts to DATABASE nodes, providing clear when-to-use and scope boundaries.
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, safe operation. Description adds value by detailing returned data (field definitions, targetDatabaseId, config) and linking to response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant text. Efficient and actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple read operation: explains what it returns, when to use, and requires no additional context given annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter described). Description does not add extra meaning beyond 'FORM node id', which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it reads a Rootr FORM node and lists specific contents (field definitions, targetDatabaseId, config). Distinguishes from sibling tools by focusing on form configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use before rootr_update_form to keep field ids stable, or before rootr_list_form_responses to know field ids. Provides clear when-to-use 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds value by specifying what is read (theme and full slides array) and that it is a read operation, consistent with annotations. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose followed by usage guidance. Every sentence is concise and essential. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, read-only, no output schema), the description is complete: it states what is read and when to use it. No missing information for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with description 'PRESENTATION node id' for presentationId. Description does not add extra parameter details beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Read' and resource 'PRESENTATION node', and explicitly states it returns 'its theme and full slides array'. Clearly distinguishes from sibling tools by mentioning related mutation 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this tool before specific mutation tools (rootr_update_presentation, rootr_append_presentation_slides, rootr_reorder_presentation_slides) to know current slide ids and content. Provides clear when-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?
The description adds critical behavioral context beyond the annotations (destructiveHint: true) by explaining the full replacement semantics and that omitted fields will be dropped. This prevents misuse and aligns well with 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a warning, focused and front-loaded. Every sentence serves a clear purpose with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (full replace, destructive), the description provides sufficient context: warning about replacement, guidance to read first, and implicit need to preserve all fields. No output schema is needed as the action is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add additional semantic meaning beyond what is already in the input schema for the parameters logId and fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates the field schema of an existing LOG store and emphasizes it is a full replace. This distinguishes it from partial updates and sibling tools, making the specific verb+resource+scope very clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to read the current fields first (e.g., via rootr_read) and warns about the full replace behavior. However, it does not explicitly specify when not to use this tool or suggest alternatives for partial updates, leaving minor room for improvement.
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=true and destructiveHint=false, indicating a safe read operation. The description adds behavioral context about key type differences, which goes beyond annotations. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a purpose: first states the action, second adds key-type nuance, third gives usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and annotations covering safety, the description fully explains the tool's behavior and use case. It helps differentiate from many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description does not need to add parameter information. Baseline score of 4 applies when no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the Rootr workspaces' with a specific verb and resource. It distinguishes behavior by key type (account vs workspace key), which differentiates it from sibling tools that are workspace-scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (to list workspaces and find workspace IDs) and implies it's a prerequisite for other workspace-scoped tools. It does not explicitly state when not to use, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) don't fully describe behavior, but the description adds that it is 'conflict-free, additive operation — it never overwrites existing content.' This discloses the key trait beyond annotations. However, it could mention error handling or behavior if target document doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence clearly defines the action, and the second provides usage guidance and benefit. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple append tool with three parameters, the description covers the core behavior and usage context. It lacks details on what happens if the target document doesn't exist or if the heading is misspelled, but given the simplicity, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 extra context for 'underHeading' by clarifying that a missing heading section is created at the document end, which is not in the schema. It also reinforces that content is Markdown. This additional guidance raises the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool appends content to a Rootr document with an optional heading. It distinguishes from sibling rootr_write by explicitly recommending this tool for adding new information. The verb 'append' and resource 'Rootr document' are specific 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'prefer this over rootr_write whenever you just need to add new information (log entries, notes, findings) to an existing document.' It also explains why it's preferred (conflict-free, additive). No exclusions needed, but strong context is provided.
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 non-readonly, non-destructive. Description adds critical context: field type details, options structure, id stability warning, and the effect of targetDatabaseId. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph is dense but well-organized: purpose first, then usage hints, then parameter details and a warning. No wasted sentences; could benefit from slight structuring.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (7 params, nested objects, no output schema), description covers essential behavior: creation, field types, options, id management, and response mirroring. Provides enough context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaning by explaining field types, options requirements, id stability, and the purpose of targetDatabaseId, going beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new FORM node (fillable intake) in a Rootr workspace, optionally seeded with fields. It specifies use for surveys/request queues, distinguishing it from sibling tools like rootr_read_form or rootr_update_form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use FORM (surveys/request queues) and mentions setting targetDatabaseId to mirror responses. Advises reading the form before updating to keep field ids stable, but does not explicitly contrast with other creation tools.
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 (readOnlyHint=false, destructiveHint=false), the description reveals critical behaviors: the response secret is shown only once, debounceSeconds has a server-enforced cap, and the loop guard with actorId. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with a clear purpose, then providing details in a structured manner. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema, the description covers important behavioral context (secret visibility, loop guard, debounce cap). However, it could mention the undefined return type briefly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 explaining scope to subtree (scopeNodeId), tag filtering (filterTags), and debounce behavior (trailing, server-capped), which go beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Create a webhook on a Rootr workspace' and lists valid events, clearly stating the tool's purpose. It distinguishes from siblings like rootr_list_webhooks and rootr_delete_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance through IMPORTANT and LOOP GUARD warnings, explaining when to copy the secret and how to avoid self-triggering loops. It doesn't explicitly list alternatives but implies appropriate 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns 'your access level' and that includeSummary merges additional fields, which is consistent and informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The main purpose is front-loaded, but a lengthy paragraph about Rootr CRM general feature adds unnecessary verbosity, reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only fetch with no output schema, the description covers what is returned (pipelines, fields, config, etc.) and provides usage context. The extra paragraph is not essential but adds background.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described). The description adds context that includeSummary merges 'stage-value/forecast/win-rate summary', providing more meaning than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a Rootr CRM node' and lists its contents (pipelines, fields, config, counts, access level). It distinguishes from siblings like rootr_crm_get_deal by positioning it as a prerequisite for updates and deal creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this before rootr_crm_update or before creating deals' and explains the optional includeSummary parameter for merging summary data, providing clear when-to-use and how-to-use guidance.
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 non-read-only and non-destructive. Description adds that the tool fails with a clear error if snippet is missing or ambiguous (not unique), and hints at replaceAll behavior. Behavior is well-disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first describes the operation, second explains error handling and prerequisite, third provides usage guidance and alternative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool's purpose, error behavior, and usage compared to sibling are covered. No output schema, but mutation tool return values are typically obvious. Could mention idempotency or effect on document structure, but sufficient for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage). Description adds context that 'find' must be exact and unique unless replaceAll is set, slightly enhancing semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it replaces an exact snippet of text with new text in a Rootr document. Distinguishes itself from rootr_append, which is for adding new content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it (precise targeted edits) and when to use rootr_append (adding new content). Also advises reading the document first to copy exact text, providing a prerequisite.
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 declare readOnlyHint=false and destructiveHint=false. Description adds owner-level action, permission requirements, key type constraints, and side effects (public readability, edit suggestions). 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose. Contains multiple pieces of information but each sentence adds value. Slightly long but not excessive for the detail needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers what, why, how (permissions), related tools, and return value. No gaps noted given the tool's simplicity and available annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'target' is fully described in schema (100% coverage). Description does not add new meaning beyond 'Document path or node id', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Publish', resource 'Rootr document', and specific outcome 'public read-only URL'. Distinguishes from sibling tools 'rootr_document_public_status' and 'rootr_set_document_public'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (publishing), prerequisites (MANAGE permission, account key), what to check first ('rootr_document_public_status'), and alternative for unpublishing ('rootr_set_document_public'). Also clarifies key restrictions.
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 readOnlyHint=true and destructiveHint=false. Description adds behavioral context: it returns a questionPolicy, requires generating questions, and mandates user interaction. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with critical instruction 'ALWAYS call this first'. Although slightly verbose, every sentence adds specific value, covering workflow steps and constraints. Could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and no output schema, the description fully covers the tool's purpose, expected output (questionPolicy, dimensions, buildingBlocks), and required follow-up actions. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'intent' parameter. Description adds value by explaining that intent is a natural-language description and provides examples, going beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it is 'Step 1 of scaffolding' and its function: planning a workspace scaffold from a natural-language intent. Distinguished from sibling tools like rootr_scaffold_apply which applies the plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'ALWAYS call this first' and 'Never build straight from a one-line intent'. Provides clear context for when to use and directs to subsequent tools like rootr_create_workspace or rootr_scaffold_apply.
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 (readOnlyHint=false) indicate mutation, and the description fully discloses the creation behavior. It reveals important behavioral details: diagrams/images are not indexed, images require prior upload, page numbers are auto-generated for certain slide kinds, and the canvas is 1280x720. These beyond-annotation details give the agent a clear understanding of side effects and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured: it begins with the core purpose, then flows into authoring guidelines, image specifics, slide roles, and page number behavior. Every sentence adds value, though some details (e.g., the exact mermaid diagram type) could be omitted. It is front-loaded with the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects for slides, blocks, images), the description covers all critical aspects: canvas size, knowledge graph indexing, image sourcing workflow, slide kind semantics, layout hints, and auto-numbering. It also references sibling tools for auxiliary tasks. No output schema is present, but the description sufficiently explains what the tool produces.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant semantic value beyond the input schema. It explains the authoring guide for slides (assertion-style titles, blocks structure), image handling (alt text importance, upload process, placement), diagram constraints, and the role of 'kind'. This helps the agent construct complex nested objects correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a new PRESENTATION node (a slide deck)'. It specifies the resource (presentation), action (create), and context (Rootr workspace). This distinctively sets it apart from siblings like rootr_read_presentation or rootr_update_presentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive usage guidance on how to author slides, including assertion-style titles, blocks, diagrams, images, and slide roles. It references complementary tools (rootr_generate_image, rootr_remove_image_background). However, it does not explicitly contrast with sibling tools or state when to use this tool versus alternatives; the guidance is more about effective usage than selection criteria.
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 authorization requirements, tree size limit, and after-creation behavior, adding significant context beyond the annotations which only indicate non-read-only and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but each sentence adds valuable context; front-loaded with core action and critical instructions, making it effective for agent use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensively covers prerequisites, tree design guidance, and next steps, making it complete for a complex creation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters; description enriches by explaining the tree structure expectations and the purpose of the intent parameter, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new Rootr workspace from a scaffold tree, distinguishing it from other creation tools like rootr_create_presentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions required scope, precondition to call rootr_scaffold_plan first, and post-creation suggestion for webhook, guiding appropriate usage.
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=true and destructiveHint=false, so the description does not need to reiterate safety. It adds value by specifying the output is 'full markdown content' and that it accepts path or node id. Could mention any permission or size limits, but not required for a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each serving a purpose. First sentence defines the action and parameters; second sentence provides usage guidance. No redundancy or extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter, readOnlyHint annotation, and no output schema, the description is complete. It tells the agent what to expect (full markdown) and how to call it (path or node id), fulfilling all information needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaningful context beyond the schema: it clarifies that path starts with '/' and that node id is an alternative. This helps the agent construct valid inputs, especially since the schema only provides a vague description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Read' with resource 'Rootr document' and explicitly mentions two identifiers (path with '/' prefix and node id). Clearly distinguishes from sibling write tools like rootr_write and rootr_append.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Read a document before editing or appending to it so you know its current structure.' This gives clear when-to-use guidance and differentiates from write 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?
Discloses non-destructive behavior by specifying existing slides are untouched. Explains page numbering auto-removes 'cover'/'closing' slides, and that diagrams/images are not indexed. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
First sentence clearly states the primary action. While the description is long, every section earns its place by providing crucial authoring guidance. Could be slightly condensed, but very well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: how to get images, upload process, background removal, knowledge graph indexing, layout hints, page numbering. No output schema needed since appending slides is straightforward. Fully adequate 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning: assertion-title format, text spine concept, image placement details, alt text necessity, kind roles. Enriches understanding beyond schema property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool appends slides to the end of a presentation without touching existing slides. It distinguishes from rootr_update_presentation by explicitly recommending this tool when only adding slides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to prefer this over rootr_update_presentation when adding slides. Provides detailed authoring guidelines for slide content, including assertion-style titles, text spine importance, and image handling. References sibling tools like rootr_generate_image and rootr_remove_image_background correctly.
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?
Describes creation behavior, scene structure, and critical detail that 'text/label' is indexed into the knowledge graph while layout is visual-only. Annotations are minimal but not contradicted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (6-7 sentences) and well-structured, front-loading purpose and usage then detailing the scene. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, scene structure, and knowledge graph implications well. However, lacks information about the return value (e.g., node ID) since no output schema is provided. Otherwise complete for a create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value by explaining the scene structure (shapes and edges), the role of text/label for indexing, and that defaults apply. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new WHITEBOARD node (a freeform visual canvas)', providing a specific verb and resource. It distinguishes from DATABASE and SPREADSHEET, and the title aligns perfectly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use 'for flow diagrams, brainstorming, journey maps' and when not 'not for anything that needs typed/trackable rows (use DATABASE) or calculation (use SPREADSHEET)'. Also advises reading before updating, providing clear 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 only indicate no read-only or destructive hint, but the description adds critical behavioral details: fields array replacement is complete (omitted fields dropped), database unlinking via null, and the importance of preserving field ids for response attribution. This goes well 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured with important points front-loaded. Each sentence provides useful information, though minor redundancy could be trimmed. Still effectively concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested fields, merge-patch semantics, database linking), the description covers all necessary aspects: field replacement behavior, id stability, type definitions, options requirement, and unlinking. No output schema, but the description adequately explains the mutation effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds significant value: explains that the fields array is replaced entirely, clarifies the role of the id field for stability, describes field types and the options structure for select types, and explains the effect of targetDatabaseId being null.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a merge-patch update on a Rootr form, specifying the verb (merge-patch), resource (form), and key behaviors like replacing the fields array or unlinking a database. It distinguishes from sibling tools like rootr_read_form by advising to read first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: call rootr_read_form first to preserve field ids, and warns about the consequences of dropping fields. It also explains how to unlink a mirrored database (targetDatabaseId: null), giving clear usage 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 discloses that passing slides replaces all existing slides (destructive behavior), and explains image indexing, page numbering, and more. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured and front-loaded with key behavior. Every sentence adds value, though a minor trim could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, nested objects, no output schema), the description is thorough: covers update semantics, slide authoring, images, usage guidelines, and sibling relationships. An agent can use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds substantial meaning: merge-patch behavior, slide replacement, authoring guide for titles, blocks, images, and knowledge graph integration. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: update a presentation by merging theme/config or replacing the slides array. It uses specific verbs and resources, and distinguishes from sibling tools for incremental 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: read presentation first, resend slides to keep, or use alternative tools for incremental changes. Authoring guidelines for slides are also given.
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 (readOnlyHint=false, destructiveHint=false), the description explains the merge-patch behavior and that it does not affect other slides. It also includes extensive context on how the slide content is processed (text spine, visual-only diagrams, image handling).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and usage guidelines. The description is long due to extensive authoring tips, which are helpful but could be considered verbose. Still, every part contributes to correct tool usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested objects and 100% schema coverage but no output schema, the description covers all necessary aspects: when to use, how to obtain the slideId, how to construct the slide object (including images, diagrams, notes), and the authoring philosophy. An agent would have sufficient guidance to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant value: e.g., for 'slide.title' it says 'Assertion-style title (the claim this slide makes)', for 'alt' it explains its role in the knowledge graph, and for images it details the upload workflow. This goes well beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Merge-patch a single slide by slideId, without touching the rest of the deck,' clearly stating the action (update) and the resource (one slide). It distinguishes from sibling rootr_append_presentation_slides by contrasting use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('precise, targeted edit') and when not to ('use rootr_append_presentation_slides instead for adding new slides'). Also provides a prerequisite: 'Call rootr_read_presentation first to get the exact slideId.' No room for ambiguity.
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 clearly discloses the key behavioral trait: passing the 'sheets' parameter replaces every existing sheet, which is destructive despite annotations saying destructiveHint=false. The warning about reading first adds important context. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences with no wasted words. Key information is front-loaded: 'Merge-patch a Rootr spreadsheet'. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutating with conditional destructive behavior) and lack of output schema, the description is complete. It covers the main operations (config/icon update vs. sheet replacement), warns about destructive behavior, suggests prerequisite actions, and points to alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 by explaining that 'sheets' replaces the entire array and that omitted existing sheets are dropped, which goes beyond the schema description. This justifies a score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Merge-patch a Rootr spreadsheet: update config/icon, or REPLACE THE WHOLE sheets array'. It distinguishes itself from sibling tools like rootr_create_sheet and rootr_patch_spreadsheet_cells by explaining 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'call rootr_read_spreadsheet first and resend sheets you want to keep, or prefer rootr_create_sheet / rootr_patch_spreadsheet_cells for incremental changes'. This clearly tells the agent when to use this tool and when to use alternatives.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/gwmage/rootr-cli'
If you have feedback or need assistance with the MCP directory API, please join our Discord server