Enables searching inbox, reading full email content, and sending emails through Gmail API integration
Uses Google Apps Script as a web app backend to facilitate API connections between the MCP server and Google services
Provides comprehensive revenue tracking, lead pipeline management, knowledge matrix documentation, and task management through Google Sheets integration
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Revenue Engine MCP show me the current revenue dashboard"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that connects Claude AI to Google Sheets, Gmail, and Calendar for comprehensive revenue tracking and business management.
📊 Revenue Dashboard - Real-time tracking of leads, revenue, and metrics
🔄 Lead Pipeline Management - Track leads from contact to close
📧 Gmail Integration - Search, read, and send emails
📅 Calendar Integration - Manage meetings and schedules
✅ Task Management - Track tasks and time
📝 Knowledge Matrix - Structured documentation with automated analysis
🐛 Bug Tracking - UID-based bug tracking system
📂 File Operations - Read, write, and edit local files
Related MCP server: GoHighLevel MCP Server
Node.js >= 18.0.0
Google Account with access to Sheets, Gmail, and Calendar
Claude Desktop app
Clone the repository
git clone https://github.com/YOUR_USERNAME/revenue-engine-mcp.git
cd revenue-engine-mcpInstall dependencies
npm installConfigure Claude Desktop
Add to your claude_desktop_config.json:
{
"mcpServers": {
"revenue-engine": {
"command": "node",
"args": ["C:\\path\\to\\revenue-engine-mcp\\index.js"]
}
}
}Deploy Google Apps Script
Set up your Google Apps Script web app
Update the API_URL in index.js with your deployment URL
Restart Claude Desktop
get_dashboard - Get current revenue metrics
get_pipeline - View all leads
add_lead - Add new lead
update_lead - Update lead status
add_revenue - Log closed deal
search_gmail - Search inbox
get_email_content - Read full email
send_email - Send email
get_upcoming_meetings - View calendar
setup_matrix_sheet - Initialize Matrix
write_matrix_entry - Log work
matrix_daily_summary - Generate daily summary
matrix_time_analysis - Analyze time spent
add_task - Create task
get_tasks - View all tasks
update_task - Update task status
read_file - Read file contents
edit_file - Surgical file editing
write_file - Write/update files
run_command - Execute shell commands
See Full Specification for complete documentation.
Current version: 1.7.0
MIT
Add a new lead to the pipeline
| Name | Required | Description | Default |
|---|---|---|---|
| companyName | Yes | Company name | |
| contactName | No | Contact person name | |
| contactEmail | No | Contact email | |
| contactPhone | No | Contact phone | |
| industry | No | Industry/sector | |
| source | No | Lead source | |
| estimatedValue | No | Estimated project value | |
| servicesInterestedIn | No | Services interested in | |
| notes | No | Additional notes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Add' implies a write/mutation operation, it doesn't specify permissions required, whether the operation is idempotent, what happens on duplicate entries, or what the response looks like. This leaves significant behavioral gaps for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary elaboration. It's appropriately sized and front-loaded, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It doesn't address behavioral aspects like error conditions, response format, or system constraints that would help an agent use this tool effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing complete parameter documentation. The description adds no additional parameter semantics beyond what's in the schema, but with full schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a new lead') and the target resource ('to the pipeline'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'update_lead' or 'check_new_leads', which would require explicit comparison to achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'update_lead' or 'check_new_leads'. There's no mention of prerequisites, appropriate contexts, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a closed deal
| Name | Required | Description | Default |
|---|---|---|---|
| clientName | Yes | ||
| leadId | No | ||
| serviceType | No | ||
| projectDescription | No | ||
| contractValue | Yes | ||
| status | No | ||
| paymentReceived | No | ||
| notes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Add a closed deal' implies a write operation that creates a new record, but it doesn't specify permissions needed, whether it's idempotent, what happens on duplicate entries, or the response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the core action without unnecessary elaboration. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, mutation operation) and lack of annotations or output schema, the description is incomplete. It doesn't explain the tool's behavior, parameter meanings, or what to expect upon execution. For a tool that likely modifies data and has multiple inputs, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. With 8 parameters and 0% schema description coverage, the schema only defines types and enums without explanations. The description doesn't clarify what 'clientName', 'contractValue', or other fields mean in context, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a closed deal' clearly states the verb ('Add') and resource ('closed deal'), making the purpose understandable. It distinguishes from siblings like 'add_lead' or 'add_task' by specifying the type of record being added. However, it doesn't explicitly mention revenue or financial aspects that the tool name suggests, which could be slightly more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'add_lead', 'update_lead', and 'log_daily_metrics', there's no indication of prerequisites (e.g., whether a lead must exist first) or context for choosing this over similar tools. It merely states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new task
| Name | Required | Description | Default |
|---|---|---|---|
| taskDescription | Yes | ||
| priority | No | ||
| dueDate | No | YYYY-MM-DD | |
| relatedTo | No | ||
| estimatedHours | No | ||
| notes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers none. 'Add a new task' implies a write/mutation operation, but the description doesn't address permissions needed, whether the operation is idempotent, what happens on success/failure, or any rate limits. For a creation tool with zero annotation coverage, this is critically insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words with no wasted language. While this conciseness comes at the expense of completeness, the description itself is efficiently structured 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 6-parameter creation tool with no annotations, no output schema, and only 17% schema description coverage, the description is completely inadequate. It provides no information about the tool's behavior, parameters, usage context, or expected outcomes. The agent would struggle to use this tool correctly based solely on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only 'dueDate' has a description), leaving 5 parameters undocumented in the schema. The description 'Add a new task' provides zero information about any parameters - it doesn't mention required fields like 'taskDescription', optional fields like 'priority' with its enum values, or what 'relatedTo' or 'estimatedHours' mean. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a new task' restates the tool name 'add_task' without providing additional specificity. While it indicates the verb ('add') and resource ('task'), it doesn't distinguish this from sibling tools like 'update_task' or clarify what kind of task system this operates within. This is essentially a tautological restatement of the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of when to choose 'add_task' over 'update_task' or 'get_tasks', nor any context about prerequisites, appropriate scenarios, or exclusions. The agent receives zero usage direction from this description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check for new leads added in last 24 hours that need welcome emails
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool checks for leads needing welcome emails, but doesn't describe what 'check' entails (e.g., returns a list, triggers notifications, requires authentication, has rate limits, or what happens if no leads are found). For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Check for new leads added in last 24 hours that need welcome emails.' It is front-loaded with the core purpose, has no redundant words, and efficiently conveys the essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and 0 parameters, the description provides a basic purpose but lacks details on behavior, return values, or error handling. It's minimally adequate for a simple check operation but doesn't fully compensate for the absence of structured data, leaving gaps in understanding how the tool functions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, which is appropriate since there are no parameters to describe. This aligns with the baseline expectation for zero-parameter tools, where minimal param info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check for new leads added in last 24 hours that need welcome emails.' It specifies the verb ('check'), resource ('new leads'), and temporal scope ('last 24 hours'), though it doesn't explicitly differentiate from sibling tools like 'get_metrics' or 'get_pipeline' which might also retrieve lead data. The purpose is specific but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it should be used when checking for recent leads requiring welcome emails. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_metrics' or 'update_lead', nor does it mention prerequisites or exclusions. The usage is implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete rows from Knowledge Matrix with confirmation requirement. First call shows preview, second call with confirm=true executes deletion. Cannot delete header rows (1-2).
| Name | Required | Description | Default |
|---|---|---|---|
| startRow | Yes | First row to delete (must be >= 3) | |
| endRow | Yes | Last row to delete (inclusive) | |
| confirm | No | Set to true to actually delete (first call without this shows preview) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by describing the two-step confirmation process and the restriction on header rows, which are critical behavioral traits. However, it lacks details on error handling, permissions needed, or what the preview shows, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, followed by essential details in two concise sentences. Every sentence adds value: the first explains the action and confirmation requirement, the second clarifies the process and restrictions, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description does a good job covering key aspects like the confirmation flow and restrictions. However, it lacks information on return values, error cases, or side effects, which would enhance completeness for such a critical operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds context about the confirmation process and header row restriction, which relates to parameters but doesn't provide additional semantic details beyond what's in the schema. This meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete rows from Knowledge Matrix') and distinguishes it from siblings by specifying the resource ('Knowledge Matrix'), which is unique among the listed tools. It also mentions the confirmation requirement, adding specificity beyond just the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: it explains the two-step process (first call for preview, second with confirm=true for execution) and includes a restriction ('Cannot delete header rows (1-2)'). This gives clear instructions on when and how to use the tool effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Surgically edit a file by finding and replacing exact text. 50% more efficient than read+write. Use after read_file to ensure exact match. Errors if text not found or appears multiple times. Creates backup automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Full file path | |
| find | Yes | Exact text to find (must match exactly including whitespace) | |
| replace_with | Yes | Text to replace it with |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so effectively: it discloses error conditions ('Errors if text not found or appears multiple times'), efficiency claims ('50% more efficient'), and safety features ('Creates backup automatically'), offering clear behavioral context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: it starts with the core action ('Surgically edit a file'), followed by efficiency, usage tip, error conditions, and backup feature—each sentence adds essential information with zero waste, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides strong context for a mutation tool: it covers purpose, usage, errors, and safety. However, it lacks details on return values or specific error formats, leaving a minor gap in completeness for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the input schema already documents all parameters well. The description adds minimal value by implying the 'find' parameter requires exact matches, but this is largely redundant with the schema's description. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('surgically edit', 'find and replace exact text') and resource ('a file'), distinguishing it from sibling tools like read_file and write_file by emphasizing its specialized text replacement functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use after read_file to ensure exact match' specifies a prerequisite, and it implicitly contrasts with alternatives like write_file by noting '50% more efficient than read+write', helping the agent choose this tool for targeted edits over broader file operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current revenue dashboard with all key metrics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read operation ('Get') but doesn't specify whether it requires authentication, has rate limits, returns real-time or cached data, or what happens on errors. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is adequate but has clear gaps. It lacks behavioral details (e.g., authentication needs, data freshness) and usage guidelines compared to siblings, making it minimally viable but not fully complete for informed tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by clarifying the scope ('current revenue dashboard with all key metrics'), which isn't captured in the schema, earning a score above the baseline of 3 for such cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('current revenue dashboard with all key metrics'), making it easy to understand what it does. However, it doesn't explicitly distinguish itself from sibling tools like 'get_metrics' or 'get_pipeline', which might also retrieve related data, so it misses the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_metrics' and 'get_pipeline' that might retrieve similar or overlapping data, there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full content of an email thread by ID. Returns complete email body, attachments info, and all messages in the thread.
| Name | Required | Description | Default |
|---|---|---|---|
| threadId | Yes | Gmail thread ID (get this from search_gmail results) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what is returned (full content, attachments, messages) but lacks details on error handling, rate limits, authentication needs, or whether it's read-only (implied by 'Get' but not explicit). This is adequate but has clear gaps for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste: the first states the purpose and parameter, the second specifies the return values. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, parameter context, and return values. However, without annotations or output schema, it could benefit from more behavioral details (e.g., error cases), preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does 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 single parameter. The description adds value by clarifying the parameter's purpose ('Get full content of an email thread by ID') and indirectly linking it to search_gmail, but does not provide additional syntax or format details beyond the schema. With only one parameter, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get full content'), resource ('an email thread by ID'), and scope ('complete email body, attachments info, and all messages in the thread'), distinguishing it from sibling tools like search_gmail which likely returns metadata or summaries rather than full content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'get this from search_gmail results' in the schema, suggesting this tool is used after search_gmail to retrieve detailed content. However, it does not explicitly state when not to use it or name alternatives, keeping it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all topics for a specific date. Returns complete row from Matrix.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date in YYYY-MM-DD format (defaults to today) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it returns a complete row, lacking details on permissions, rate limits, error handling, or what 'complete row' entails (e.g., data format, size). It mentions the return but doesn't disclose behavioral traits beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded and efficient, stating purpose and return value without waste. Every sentence earns its place, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It doesn't explain return values (e.g., what 'complete row' includes), error cases, or usage context, leaving gaps for a tool that retrieves data from a matrix.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'date' fully documented in the schema. The description adds no additional meaning beyond implying date filtering, so it meets the baseline of 3 without compensating or enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('all topics for a specific date'), specifying it returns a complete row from the Matrix. It distinguishes from siblings like 'query_matrix' or 'matrix_daily_summary' by focusing on row retrieval by date, but doesn't 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'query_matrix' or 'matrix_daily_summary', which might offer similar or overlapping functionality. The description implies usage for date-specific row retrieval but lacks explicit when/when-not instructions or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent daily metrics (last 7 days)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves metrics but doesn't specify what 'metrics' include, whether it's read-only (implied by 'Get'), any rate limits, authentication needs, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core purpose ('Get recent daily metrics') and adds necessary context ('last 7 days') without redundancy. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic action and time scope but lacks details on what 'metrics' include, return format, or error cases. For a read operation with low complexity, it meets the baseline but doesn't provide full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by specifying the time scope ('last 7 days'), which isn't captured in the schema. This compensates adequately, though it doesn't fully explain what 'metrics' entail, keeping it from a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('recent daily metrics') with a specific time scope ('last 7 days'). It distinguishes from siblings like 'get_dashboard' or 'get_matrix_row' by focusing on metrics over a fixed period. However, it doesn't explicitly differentiate from potential similar tools (e.g., 'matrix_daily_summary'), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to siblings like 'get_dashboard' or 'matrix_daily_summary' that might overlap in functionality. The lack of usage context leaves the agent guessing about appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all leads in the pipeline
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get all leads' but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, how data is returned (e.g., pagination, format), or any rate limits. This leaves significant gaps for a tool with potential data retrieval implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of retrieving 'all leads' (which could involve large datasets), no annotations, and no output schema, the description is incomplete. It lacks details on return values, data structure, or any constraints, making it inadequate for informed tool selection by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, but that's acceptable here as there are no params to explain, warranting a baseline score above minimum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('all leads in the pipeline'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_metrics' or 'get_dashboard' that might also retrieve data, so it lacks sibling distinction for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'check_new_leads' or 'update_lead' that might handle leads differently, there's no indication of context, prerequisites, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all tasks
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Get all tasks' implies a read operation but doesn't disclose important behavioral traits like whether this returns all tasks at once (potential performance implications), what format the tasks are returned in, whether there are permissions required, or if there are rate limits. The description provides 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words. It's front-loaded with the essential action and resource. There's zero wasted language or unnecessary elaboration for a simple retrieval operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 0 parameters, the description is incomplete. While it states what the tool does, it doesn't provide enough context about what 'tasks' are in this system, what format they're returned in, or any behavioral constraints. The agent would need to guess about the return structure and system behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description 'Get all tasks' appropriately indicates this is a parameterless operation that retrieves all available tasks, which aligns perfectly with the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all tasks' clearly states the verb ('Get') and resource ('tasks'), but it's vague about scope and doesn't differentiate from sibling tools like 'get_matrix_row' or 'get_metrics'. It provides basic purpose but lacks specificity about what 'all tasks' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With many sibling tools including 'get_matrix_row', 'get_metrics', and 'get_pipeline', the description offers no context about when this specific task retrieval tool is appropriate versus other data retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get message templates with performance metrics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't clarify if it requires specific permissions, has rate limits, returns paginated results, or what format the performance metrics are in. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get message templates with performance metrics'. It is front-loaded with the core action and resource, with no redundant words or unnecessary elaboration. Every word earns its place by specifying what is retrieved and what additional data is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks context on behavioral traits, usage guidelines, or output details. Without annotations or an output schema, the agent won't know the return format or any operational constraints, making this incomplete for informed use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, which is appropriate since there are none to describe. According to the rules, 0 parameters warrants a baseline score of 4, as there's no need to compensate for missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get message templates with performance metrics' clearly states the verb ('Get') and resource ('message templates'), including the scope of data returned ('with performance metrics'). It distinguishes this from generic data retrieval tools like 'get_dashboard' or 'get_metrics' by specifying the resource type. However, it doesn't explicitly differentiate from all siblings (e.g., 'get_email_content' might overlap in some contexts), preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication needs), exclusions, or comparisons to similar tools like 'get_email_content' or 'get_metrics'. The agent must infer usage based on the name and description alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get upcoming meetings from Google Calendar (next 7 days)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no mention of authentication requirements, rate limits, return format (e.g., list structure, fields included), pagination, or error handling. For a read operation with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core purpose ('Get upcoming meetings') and includes essential scope ('from Google Calendar, next 7 days'). Every word earns its place, making it appropriately sized for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'upcoming meetings' means (e.g., all meetings, only owned ones), the return format, or any behavioral constraints. For a tool that likely returns structured data, more context is needed despite the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools. No additional parameter context is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'upcoming meetings from Google Calendar' with a specific time constraint 'next 7 days'. It distinguishes itself from siblings like 'get_tasks' or 'get_metrics' by focusing on calendar meetings. However, it doesn't explicitly differentiate from potential calendar-specific siblings (though none exist in the provided list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), when not to use it, or what other tools might be better for different calendar queries. The context is implied (upcoming meetings within 7 days) but lacks explicit usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log daily activity metrics
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD | |
| outreachAttempts | No | ||
| responses | No | ||
| callsBooked | No | ||
| proposalsSent | No | ||
| dealsClosed | No | ||
| revenueClosed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Log' implies a write operation, but it does not specify if this creates new records, updates existing ones, requires authentication, has side effects, or handles errors. This leaves critical behavioral traits unclear for a tool with 7 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it appropriately concise. However, it is front-loaded with minimal information, which limits usefulness despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations, no output schema), the description is incomplete. It fails to explain the tool's behavior, parameter interactions, or expected outcomes, leaving significant gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 14%, with only the 'date' parameter documented. The description does not explain the meaning of parameters like 'outreachAttempts' or 'revenueClosed', nor does it clarify relationships between them (e.g., if 'callsBooked' is a subset of 'responses'). It adds no semantic value beyond the basic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Log daily activity metrics' restates the tool name 'log_daily_metrics' with minimal elaboration, making it tautological. It specifies the action ('log') and resource ('daily activity metrics') but lacks detail on what 'log' entails (e.g., create, update, store) or how it differs from sibling tools like 'log_outreach' or 'matrix_daily_summary', leaving purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., daily reporting), or exclusions, and fails to differentiate from similar tools like 'log_outreach' or 'matrix_daily_summary', offering no usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log an outreach activity
| Name | Required | Description | Default |
|---|---|---|---|
| leadId | No | ||
| companyName | Yes | ||
| channel | Yes | ||
| templateUsed | No | ||
| templateId | No | ||
| responseReceived | No | ||
| responseType | No | ||
| notes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Log an outreach activity' implies a write operation but doesn't specify whether this creates new records, updates existing ones, requires permissions, or has side effects. It lacks details on response format, error handling, or system impacts, leaving significant gaps for a tool with 8 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, 0% schema coverage, no output schema, and no annotations, the description is inadequate. It doesn't explain what constitutes an 'outreach activity', how logging integrates with sibling tools, or what happens after logging. The minimal description fails to provide necessary context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'leadId', 'channel', 'responseType', or other parameters mean in context, nor does it clarify relationships between parameters like 'templateUsed' and 'templateId'. This leaves all 8 parameters semantically undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Log') and resource ('outreach activity'), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'log_daily_metrics' or 'add_lead', but it's specific enough to convey the core function without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'add_lead', 'update_lead', or 'log_daily_metrics'. There's no mention of prerequisites, timing, or context for logging outreach activities, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate formatted summary of Matrix entries for a specific date. Automatically parses timestamps, bug UIDs, time spent, and generates human-readable output.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date in YYYY-MM-DD format (defaults to today) | |
| format | No | Output format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'automatically parses timestamps, bug UIDs, time spent, and generates human-readable output,' which gives some insight into its processing behavior. However, it lacks details on error handling, performance characteristics (e.g., rate limits), or any side effects, which are important for a tool that processes data. The description doesn't contradict annotations, but it's insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core purpose in the first sentence. The second sentence adds useful details about parsing and output generation without redundancy. It's appropriately sized for the tool's complexity, with no wasted words, though it could be slightly more structured to highlight key points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It explains what the tool does and its output format, but lacks details on error cases, input validation, or how it interacts with sibling tools. Without an output schema, more information on return values would be helpful, but the description doesn't provide this, leaving room for improvement in overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('date' and 'format'), including enum values for 'format'. The description adds minimal value beyond the schema, as it doesn't elaborate on parameter usage or provide examples. Since the schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate with additional semantic insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate formatted summary of Matrix entries for a specific date.' It specifies the verb ('generate'), resource ('Matrix entries'), and scope ('for a specific date'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'matrix_time_analysis' or 'query_matrix', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions what the tool does but doesn't indicate scenarios where it's preferred over siblings like 'matrix_time_analysis' or 'query_matrix', nor does it mention prerequisites or exclusions. This lack of context could lead to confusion in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze time spent across Matrix entries. Tracks total time by topic, bug UID, or week. Parses time markers like [30m], [2h] from entries.
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | No | Start date YYYY-MM-DD (optional, defaults to beginning) | |
| endDate | No | End date YYYY-MM-DD (optional, defaults to today) | |
| groupBy | No | How to group the analysis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions parsing time markers and grouping analysis, but doesn't describe output format, error handling, or performance characteristics. For a tool with 3 parameters and no output schema, this leaves significant gaps in understanding how results are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the core purpose and grouping options, the second explains the parsing mechanism. Every sentence adds value with zero waste, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the analysis output looks like, how time markers are parsed, or any limitations. For a tool that performs analysis with multiple grouping options, more context about result format and behavior is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters with descriptions and enum values. The description adds marginal value by mentioning 'tracks total time by topic, bug UID, or week' which aligns with the groupBy parameter, but doesn't provide additional syntax or format details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze time spent across Matrix entries' with specific actions like tracking total time by topic, bug UID, or week, and parsing time markers. It distinguishes from siblings by focusing on time analysis rather than general matrix operations like query_matrix or matrix_daily_summary, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for analyzing time from Matrix entries with time markers, but doesn't explicitly state when to use this tool versus alternatives like matrix_daily_summary or query_matrix. No exclusions or prerequisites are mentioned, leaving the agent to infer context from the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Matrix for keyword across topics and dates
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Search term | |
| topics | No | Topics to search (optional, defaults to all) | |
| limit | No | Max results (default 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Search' implies a read-only operation, the description doesn't address important behavioral aspects like whether this is a real-time search, how results are sorted/ranked, pagination behavior, performance characteristics, or any rate limits. The description is too minimal for a search tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, with zero wasted language. It's front-loaded with the core functionality and efficiently communicates the essential purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what kind of results to expect, the format of returned data, error conditions, or how the search operates across the mentioned 'topics and dates' dimensions. The agent would be left guessing about important behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all three parameters thoroughly. The description mentions 'keyword across topics and dates' which aligns with the schema parameters but doesn't add meaningful semantic context beyond what the schema provides. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as searching the Matrix for a keyword across topics and dates, which is a specific verb+resource combination. However, it doesn't distinguish this tool from potential sibling search tools like 'search_gmail' or 'read_matrix_snapshot' that might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that could involve searching or reading data (search_gmail, read_matrix_snapshot, get_matrix_row, etc.), there's no indication of when this specific search tool is appropriate versus other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read contents of a file. Only works in allowed directories: revenue-engine-mcp, apps-script folders
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Full file path (e.g., C:\Users\Node1\revenue-engine-mcp\index.js) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about directory restrictions, which is not in the schema, but lacks details on permissions, error handling, or output format (e.g., text, binary). This is adequate but has clear gaps for a read operation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and adds necessary constraints in the second. Both sentences earn their place by providing essential information without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is minimally complete for a simple read tool with one parameter. It covers the action and constraints but lacks details on return values or error cases, which could be important for agent invocation. This is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the 'path' parameter fully documented in the schema. The description adds no additional parameter details beyond implying path constraints via allowed directories, which is minimal value. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Read contents') and resource ('a file'), distinguishing it from sibling tools like 'edit_file' or 'write_file' which modify files. It also specifies the scope ('Only works in allowed directories'), making the purpose unambiguous and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool by specifying the allowed directories ('revenue-engine-mcp, apps-script folders'), which helps guide usage. However, it does not explicitly mention when not to use it or name alternatives like 'get_email_content' for different file types, leaving some gaps in comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Matrix entries for a date range. Returns all entries for specified topics and dates.
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | No | Start date YYYY-MM-DD (optional, defaults to beginning) | |
| endDate | No | End date YYYY-MM-DD (optional, defaults to today) | |
| topics | No | Array of topics to include (optional, defaults to all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it indicates this is a read operation and describes the return scope ('all entries for specified topics and dates'), it lacks important behavioral details like whether results are paginated, what format the entries are returned in, potential rate limits, authentication requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two clear sentences that efficiently communicate the core functionality. The first sentence states the action and scope, while the second clarifies what's returned. No wasted words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 3 parameters and no output schema, the description is insufficient. It doesn't explain the return format, data structure, or what 'Matrix entries' actually contain. With multiple similar Matrix tools in the sibling list, the lack of differentiation guidance is a significant gap in contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters. The description adds minimal value beyond what's in the schema - it mentions date range and topics filtering but provides no additional semantic context about parameter usage, constraints, or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Read') and resource ('Matrix entries'), and specifies scope ('for a date range'). However, it doesn't explicitly differentiate from sibling tools like 'get_matrix_row', 'query_matrix', or 'matrix_daily_summary', which appear to be related Matrix operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple Matrix-related siblings (get_matrix_row, query_matrix, matrix_daily_summary, matrix_time_analysis), there's no indication of how this tool differs in scope, filtering capabilities, or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute allowed shell commands (clasp, npm, git, dir). For clasp commands, run from apps-script folder.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Command to run (must be in allowed list) | |
| workingDirectory | No | Directory to run command in (optional, defaults to revenue-engine-mcp) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the allowed command list and a working directory default, but fails to disclose critical behavioral traits such as security implications, error handling, output format, permissions required, or rate limits. For a tool that executes shell commands—a potentially high-risk operation—this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded and efficient. The first sentence states the core purpose and allowed commands, while the second adds specific guidance for clasp commands. There is no wasted text, and each sentence earns its place by providing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing shell commands (a high-risk operation), lack of annotations, and no output schema, the description is incomplete. It covers the basic purpose and some usage notes but omits critical context such as security warnings, output behavior, error handling, and permissions. For a tool with no structured safety indicators, this leaves significant gaps for an AI agent to use it safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('command' and 'workingDirectory'). The description adds marginal value by specifying the allowed command list (clasp, npm, git, dir) and a note about clasp commands, which provides context beyond the schema's generic 'must be in allowed list'. However, it doesn't elaborate on parameter syntax, examples, or constraints beyond what's in the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Execute') and resource ('allowed shell commands'), listing the allowed commands (clasp, npm, git, dir). It distinguishes this tool from siblings by focusing on shell command execution, unlike other tools that handle leads, tasks, files, or metrics. However, it doesn't explicitly differentiate from potential similar tools not present in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by specifying allowed commands (clasp, npm, git, dir) and a special note for clasp commands ('run from apps-script folder'), which suggests when to use this tool for those specific operations. However, it lacks explicit when-not-to-use guidance or alternatives for other command types, and doesn't mention prerequisites or compare to other tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Gmail inbox. Use Gmail search syntax like 'from:email@example.com' or 'is:unread' or 'subject:proposal'
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Gmail search query (default: 'is:unread') | |
| maxResults | No | Max results (default: 25, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions search syntax but doesn't cover critical aspects like authentication requirements, rate limits, pagination behavior, error conditions, or what the return format looks like (e.g., list of message IDs vs full metadata). The description is insufficient for a tool that performs read operations on a sensitive resource like email.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first states the core purpose, the second provides essential usage examples. There's no wasted text, and information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of email search (with authentication, privacy considerations, and result formatting) and the absence of both annotations and an output schema, the description is incomplete. It doesn't address what the tool returns, error handling, or security implications, leaving significant gaps for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds minimal value beyond the schema by mentioning Gmail search syntax examples, but doesn't provide additional semantic context like how queries are interpreted or performance implications. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search') and resource ('Gmail inbox'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_email_content' or 'send_email', which would require mentioning it returns message metadata rather than content or that it's for finding emails rather than reading/sending them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance through the search syntax examples, suggesting it's for finding emails based on criteria. However, it lacks explicit when-to-use guidance versus alternatives like 'get_email_content' for reading specific emails or 'send_email' for composing messages, and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an email via Gmail. ALWAYS get user approval before calling this.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient email address | |
| subject | Yes | Email subject line | |
| body | Yes | Email body content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the need for user approval, which is valuable context about permissions/safety. However, it doesn't describe other behavioral traits like whether the email is sent immediately, potential rate limits, error conditions, or what happens on success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that are front-loaded and earn their place. The first sentence states the purpose, and the second provides critical usage guidance without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (sending emails is a mutation with potential side effects), no annotations, and no output schema, the description is somewhat incomplete. It covers the approval requirement but lacks details on behavioral outcomes, error handling, or return values. However, the strong usage guideline partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already fully documents all three parameters (to, subject, body). The description adds no additional parameter information beyond what's in the schema, resulting in the baseline score of 3 for adequate but no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('send') and resource ('email via Gmail'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_gmail' or 'get_email_content', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with 'ALWAYS get user approval before calling this,' which clearly indicates when to use this tool (with approval) and implies caution. This is a strong directive that helps the agent understand the appropriate context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-create Knowledge Matrix sheet with proper structure and headers. Run this once before using other Matrix tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool 'auto-creates' a sheet, implying a write operation, but doesn't specify behavioral traits like permissions needed, whether it overwrites existing sheets, or error handling. It adds some context about being a one-time setup, but lacks details on mutability or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: two sentences that directly state the action and usage guideline with zero waste. Every sentence earns its place by providing essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple setup with no parameters) and lack of annotations/output schema, the description is reasonably complete. It covers purpose and usage well, but could improve by adding more behavioral context (e.g., idempotency, output format). Without output schema, it doesn't explain return values, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate, but it implies the tool operates without inputs, aligning with the schema. Baseline is 4 for zero parameters, as it doesn't need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Auto-create Knowledge Matrix sheet with proper structure and headers.' It specifies the verb ('auto-create'), resource ('Knowledge Matrix sheet'), and outcome ('proper structure and headers'). However, it doesn't explicitly differentiate from siblings like 'write_matrix_entry' or 'read_matrix_snapshot', which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'Run this once before using other Matrix tools.' This clearly indicates when to use it (as an initial setup) and implies when not to (after setup or for other purposes), distinguishing it from alternatives like 'query_matrix' or 'write_matrix_entry'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing lead
| Name | Required | Description | Default |
|---|---|---|---|
| leadId | Yes | Lead ID to update | |
| status | No | ||
| estimatedValue | No | ||
| notes | No | ||
| nextAction | No | ||
| nextActionDate | No | YYYY-MM-DD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Update an existing lead' implies a mutation operation but doesn't specify permissions required, whether changes are reversible, error handling, or response format. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise - a single four-word phrase that communicates the core purpose without any wasted words. It's appropriately sized for a straightforward update operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, 33% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a successful update, what data is returned, error conditions, or business logic around status transitions. The agent lacks sufficient context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (2 of 6 parameters have descriptions). The description adds no parameter information beyond what's implied by 'update' - it doesn't explain what fields can be updated, their purposes, or constraints. With low schema coverage, the description fails to compensate for undocumented parameters like 'estimatedValue', 'notes', 'nextAction'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing lead'), making the purpose immediately understandable. It distinguishes from sibling 'add_lead' by specifying 'existing' rather than new creation. However, it doesn't specify what aspects can be updated or differentiate from other update tools like 'update_task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like needing a valid lead ID, nor does it contrast with similar operations like 'add_lead' for new leads or 'update_task' for different resources. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a task
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | ||
| status | No | ||
| actualHours | No | ||
| notes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update a task' implies a mutation operation but reveals nothing about permissions required, whether changes are reversible, side effects, error handling, or response format. This is inadequate for a tool that modifies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with just three words, the description is under-specified rather than efficiently structured. It lacks front-loaded critical information and doesn't earn its place by adding value beyond the tool name, making it ineffective despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, mutation operation), absence of annotations, and no output schema, the description is severely incomplete. It doesn't address key aspects like what the tool returns, error conditions, or practical usage details, leaving the agent ill-equipped to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about parameters—it doesn't mention 'taskId', 'status', 'actualHours', or 'notes', nor does it explain their purposes or constraints. This fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a task' is a tautology that merely restates the tool name without adding specificity. It doesn't distinguish this tool from sibling tools like 'update_lead' or 'add_task', nor does it clarify what aspects of a task can be updated beyond what's implied by the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing task ID), differentiate from sibling tools like 'add_task' or 'get_tasks', or specify appropriate contexts for task updates, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write or update entire file. Creates backup automatically. Use for complex multi-location edits or new files. Only works in allowed directories.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Full file path | |
| content | Yes | File content to write |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it writes or updates entire files, creates backups automatically, and has directory restrictions. However, it lacks details on error handling, permissions needed, or what happens if the file already exists, leaving some gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action ('write or update entire file') and uses three concise sentences that each add value: backup creation, usage context, and directory restrictions. There is no wasted text, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description covers basic behavior and constraints but lacks details on return values, error cases, or side effects. It is adequate given the simple schema but could be more complete for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('path' and 'content'). The description adds no additional meaning about parameters beyond what the schema provides, such as format examples or constraints, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'write or update' and the resource 'entire file', distinguishing it from sibling tools like 'edit_file' (which might imply partial edits) and 'read_file'. It specifies the scope as 'entire file' and mentions automatic backup creation, making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'for complex multi-location edits or new files' and 'only works in allowed directories'. However, it does not explicitly state when not to use it or name alternatives (e.g., 'edit_file' for partial edits), which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write or append entry to Knowledge Matrix. Topics: Bugs & Fixes, Features Added, Testing Results, Decisions & Direction, Documentation Updates, Next Session Goals
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date in YYYY-MM-DD format (defaults to today) | |
| topic | Yes | Matrix topic | |
| content | Yes | Entry content with timestamp (e.g., '3:45pm CST 🐛 Fixed bug in addTask') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Write or append entry' implying a mutation, but doesn't clarify permissions, whether it overwrites or appends, error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and lists topics without unnecessary details. Every part earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits like side effects, error cases, or return values, and doesn't compensate for the absence of structured data, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description lists topics but doesn't add syntax or format details beyond what the schema provides, such as explaining the 'content' format further. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Write or append entry') and resource ('Knowledge Matrix'), and lists the specific topics covered, making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'write_file' or 'edit_file', which might also involve writing operations, leaving some ambiguity about when to choose this tool over others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'write_file' or 'edit_file', nor does it mention prerequisites or exclusions. It lists topics but doesn't explain context for choosing this tool over others, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
add_leadadd_revenueadd_taskcheck_new_leadsdelete_matrix_rowsedit_fileget_dashboardget_email_contentget_matrix_rowget_metricsget_pipelineget_tasksget_templatesget_upcoming_meetingslog_daily_metricslog_outreachmatrix_daily_summarymatrix_time_analysisquery_matrixread_fileread_matrix_snapshotrun_commandsearch_gmailsend_emailsetup_matrix_sheetupdate_leadupdate_taskwrite_filewrite_matrix_entryMost tools have distinct purposes, but there is some overlap that could cause confusion. For example, 'get_matrix_row' and 'read_matrix_snapshot' both retrieve matrix data with subtle differences in scope, and 'edit_file' vs 'write_file' have overlapping file modification functions. The descriptions help clarify, but agents might misselect between similar tools.
Naming is mostly consistent with a verb_noun pattern (e.g., 'add_lead', 'get_dashboard', 'update_task'), but there are minor deviations like 'check_new_leads' (verb_adjective_noun) and 'matrix_daily_summary' (noun_adjective_noun). These inconsistencies are minor and do not severely impact readability, as the overall pattern remains clear.
With 29 tools, the count is borderline high for a revenue engine server, which typically handles sales, tasks, and metrics. While many tools are justified for diverse operations (e.g., matrix management, file editing, email handling), the set feels heavy and could be streamlined, potentially overwhelming agents with too many options.
The tool set covers a broad domain including lead management, task tracking, metrics logging, email operations, file handling, and matrix knowledge management. There are minor gaps, such as no tool for deleting leads or tasks, and limited meeting management beyond retrieval. However, core workflows are well-supported, and agents can work around these omissions.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Personal CRM for Claude. Contacts live as plain-text files in your own Google Drive.
Multiple Google accounts (Gmail, Calendar, Drive, Contacts, Tasks) in one Claude connector.
Give Claude only the Google Drive files you choose. Every action logged.
Connect any mailbox to Claude, ChatGPT & AI: read, send, reply, schedule & search emails.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/PromptishOperations/mcpSpec'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
