ProposalCraft
Server Quality Checklist
Latest release: v1.4.121
- Disambiguation2/5
The tool set contains numerous overlapping tools, such as multiple types of payment reminders (late_payment_reminder, late_payment_follow_up_email, payment_reminder_email) and follow-ups (client_followup, cold_pitch_follow_up, bid_lost_follow_up). While descriptions attempt to distinguish them, the sheer volume and similarity make it difficult for an agent to select the correct one consistently.
Naming Consistency4/5Most tools follow a consistent snake_case verb_noun pattern (e.g., save_proposal, list_proposals). However, some tools have inconsistent verb placement or very long names (e.g., conditional_proposal_acceptance_email), and a few lack the 'email' suffix present in most similar tools. Overall, the pattern is clear and readable.
Tool Count1/5With 156 tools, this server has an excessively large tool surface for a domain that could be covered with far fewer parameterized tools. This overwhelms agents and reduces usability. Most MCP servers in this domain have 5-15 tools.
Completeness4/5The tool set covers nearly every aspect of freelance client communication, from initial outreach to project completion, invoicing, and testimonials. It is comprehensive and leaves few gaps. However, the completeness is borderline excessive, contributing to the tool count problem.
Average 4.3/5 across 156 of 156 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 453 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully describe behavior. It explains tone variation by reminder number and the draft limit benefit, but does not disclose other important aspects such as whether the tool sends the email or just generates text, or any required permissions. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long, with the purpose front-loaded. It is concise, uses clear language, and every sentence provides relevant information without redundancy. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description covers the basic purpose and a key behavioral trait (tone variation), but it does not explain what the output looks like (e.g., a full email draft) or provide enough context to fully understand the tool's capabilities relative to its many siblings. It is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for each parameter, such as the meaning of 'reminder_number' (which is already described in the schema). Thus, it does not improve parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool writes polite and firm reminders for overdue invoices, and explains how tone varies by reminder number. However, it does not explicitly distinguish this tool from similar siblings like late_payment_reminder or payment_reminder_email, making it slightly less clear when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that the tool does not count against a monthly draft limit, which is a useful constraint. However, it provides no guidance on when to use this tool versus its many siblings that also handle payment reminders (e.g., late_payment_reminder, payment_overdue_final_notice_email). This omission limits its utility for correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It describes generation of a brief but does not state whether the tool creates a record, sends an email, or is idempotent. The mention 'Does not count against your monthly draft limit' hints at some system interaction but lacks clarity on side effects or persistence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences that efficiently cover purpose, content, benefits, and a usage note. It is front-loaded with the action and resource. Minor improvement could be removing the benefits sentence to be more concise, but overall it earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters (7 required) and no output schema, the description should explain what the tool returns or how the brief is delivered. It lacks details on output format, storage, or integration with other tools. The user might expect a downloadable document or inline text, which is not specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all 9 parameters. The description adds high-level context (e.g., covers scope, deliverable, deadline) but does not enhance understanding of individual parameters beyond what the schema provides. Score is baseline due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Generate a clear project brief for a subcontractor or VA'. It specifies the content covered (scope, deliverable, deadline, exclusions, payment, IP, confidentiality). This verb+resource combination is specific and distinct from sibling tools like scope_of_work or subcontractor_acceptance_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when bringing in a subcontractor and lists common problems it prevents, but does not explicitly state when not to use it or compare to alternatives among siblings (e.g., scope_of_work, subcontractor_acceptance_email). The note about draft limits is a usage detail but not a substitution guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility for behavioral disclosure. It states the tool lists proposals but omits details like read-only nature, response format, order, pagination, or filtering. The minimal description does not adequately inform the agent about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It contains no fluff or redundant information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description provides sufficient context: it lists all saved proposals used as style references. While it could mention sorting or default behavior, the simplicity of the tool makes the description nearly complete for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the description does not need to add parameter semantics. The baseline score of 3 is appropriate; the description adds no extra meaning but also does not mislead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing all saved proposals that serve as style references. This verb+resource combination (list proposals) is specific and distinguishes it from sibling tools like get_proposal, save_proposal, draft_proposal, and delete_proposal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_proposal or load_examples. It does not specify prerequisites, context, or when not to use it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description mentions 'does not count against your monthly draft limit' but does not state whether the tool sends the email or just drafts it. No mention of authorization needs, rate limits, or potential side effects. For a writing tool, minimal behavioral disclosure beyond the stated usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with motivational sentences ('One of the awkward conversations freelancers avoid'). Key information is present but could be more concise. It front-loads the main purpose but includes narrative that could be trimmed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple routes, optional parameters) and missing output schema, the description covers the main usage scenarios and inputs. However, it does not explain the output format (e.g., plain text email draft) or error conditions, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds context beyond the schema by explaining the 'route' parameter's options and gives full parameter lists with clarifications. This adds meaningful guidance for using the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes a professional response to a retainer downgrade request. It distinguishes three routes and provides examples. However, it does not explicitly differentiate from sibling tools like retainer_check_in_email or client_decline_email, but the specific scenario is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each route: 'accommodate' when fighting would cost more, 'retain' to argue for keeping current scope, 'pause' for temporary pause. It gives context for when to choose each. Missing explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a destructive action ('remove') but lacks details on irreversibility, permissions, or side effects. With no annotations, more transparency is needed for a deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple tool but lacks behavioral context (e.g., permanence of deletion). The abundance of sibling tools suggests more contextual guidance could be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, and the description adds no additional meaning beyond what the schema already provides for the 'name' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove'), the resource ('saved proposal'), and the context ('reference library'), distinguishing it from sibling tools like 'save_proposal' and 'list_proposals'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The usage is implied by the tool's name and description, but alternatives or exclusions are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It includes some useful traits (no counting against draft limit, tone guidelines), but does not clarify whether the tool sends the email or just drafts it, or any side effects like updating project records. This is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 4 sentences, front-loading the purpose. Every sentence adds value, and the structure is clear. Minor room for improvement in structuring behavioral notes more explicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple email-drafting tool with full schema coverage and no output schema, the description covers the essentials: purpose, tone, and a behavioral constraint (draft limit). It does not explain return behavior, but that is acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add much. The description does not provide additional meaning beyond the parameter descriptions in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing a professional email when missing a deadline. It specifies the resource (email) and verb (write), but does not explicitly differentiate from siblings like project_delay_warning or project_status_update, which may have overlapping use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use ('when you are going to miss a deadline or are already late'), but lacks guidance on when not to use it or alternatives among the many siblings. For example, it does not differentiate from project_delay_warning or overdue_project_timeline_update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool does not count against a monthly draft limit, which is helpful. However, it does not describe other behavioral aspects like idempotency, whether the email is sent automatically or drafted, or any side effects. The description is truthful but could be more comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three sentences: the main action, the content coverage, and a key benefit. Every sentence adds value without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters, no output schema, and no annotations, the description adequately explains the tool's purpose and content. It covers the email's structure and a unique benefit. However, it does not describe the output format (e.g., whether it returns the email text or sends it) or how parameters are combined. Minor gap for a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter described individually. The description adds value by mapping parameters to the content sections (e.g., 'completed_this_period' corresponds to 'what was completed'), clarifying their purpose in the email context. It also notes that 'your_name' is optional for sign-off.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional project status update email for clients during longer engagements, specifying the content areas (completed, next steps, blockers, timeline). While not explicitly differentiating from similar sibling email tools like 'client_check_in_email', the description is specific enough about the email type and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context ('during a longer engagement') and a benefit ('keeps clients informed without a meeting'), but lacks explicit guidance on when not to use this tool or how it compares to alternative sibling tools. No exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool writes a thank-you and mentions it does not count against a monthly draft limit, hinting at draft generation. However, it does not specify whether the tool sends the email directly, returns a draft text, or any side effects, leaving significant transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three substantive sentences: stating the purpose, outlining the three modes with context, and noting the draft limit benefit. Every sentence 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (six parameters, content generation) and the lack of an output schema, the description covers the key modes and parameter nuances. It could be slightly more complete by explicitly stating the output format (e.g., 'generates a draft email'), but it is largely adequate for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, but the description adds practical guidance beyond the schema, such as explaining the nuance of the enum values (e.g., 'won_project' being the warmest) and stating defaults. It also adds context for optional parameters like 'project_type' (makes the email specific) and 'reciprocate' (offers to return the favor). This adds meaningful value for an AI agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing a warm, specific thank-you for a referral. It distinguishes three modes (intro, had_call, won_project) which adds specificity. However, it does not explicitly differentiate from sibling tools like 'referral_request' or the similarly named 'referral_thank_you_email', which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the three scenarios for using the tool (intro, had_call, won_project), providing clear context. It does not, however, explicitly state when not to use this tool or compare it to alternatives like 'referral_request' or other thank-you tools. The motivational note about freelancers missing this moment is somewhat peripheral.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tone (factual, non-accusatory) and a benefit (no draft count), but does not describe the output format, whether it sends the email, or any side effects. The behavior is mostly clear as a text generator, but details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the purpose, then tone, then benefit. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the use case and tone but does not explain the return value (presumably the email text). With no output schema, the agent might need explicit indication of what the tool returns. While the complexity is low, the lack of return specification is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and schema descriptions are already clear. The description adds useful context, e.g., that 'days_waiting' calibrates tone, which is not in the schema. This extra meaning justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes a professional email to a client who hasn't delivered promised items, blocking the project. It distinguishes from many siblings by specifying the client's delay as the cause, but it doesn't explicitly differentiate from other client-facing emails like 'client_check_in_email' or 'client_followup', so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (project blocked by client delay) and sets tone expectations, but it lacks explicit guidance on when not to use or alternatives. For a tool among many similar email templates, this is a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'generates' an NDA and notes it does not affect draft limits, giving some insight into behavior. However, it does not explain what the tool returns (e.g., text content, downloadable file) or any side effects, which leaves moderate gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 50 words, front-loading the main purpose and key features like coverage and options. It efficiently conveys essential information without redundancy, though a slightly more structured breakdown of clauses could improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and moderate complexity, the description adequately covers the tool's purpose and key clauses. However, it lacks details about the output format or how the generated agreement is presented to the user, which is needed for complete understanding without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all six parameters with descriptions, achieving 100% coverage. The description adds minimal extra meaning beyond the schema, only reiterating the one-way/mutual option. Since schema coverage is high, a baseline of 3 is appropriate, and the description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a Non-Disclosure Agreement for freelance client work, specifying it covers confidentiality, duration, exceptions, and remedies. It distinguishes between one-way and mutual NDAs, and notes it is not a substitute for legal advice. This effectively differentiates it from sibling tools like contract_template, which likely cover other contract types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by indicating the NDA is for 'freelance client work' and 'standard freelance engagements,' and it explicitly notes it does not count against a monthly draft limit. However, it does not mention when to avoid using this tool or suggest alternatives like contract_template for other legal documents, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It notes that 'does not count against your monthly draft limit' but does not clarify whether the tool sends the email or just generates its content. Missing details on permissions, side effects, or delivery behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the main action and then listing details. It is concise enough to convey key points without extraneous content, though it could be slightly shorter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives good context for when to use and what the tool accomplishes, but it does not specify the output (e.g., returns email text) or how the result is presented. Without an output schema, this information would be helpful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context (e.g., examples of what to ask) but does not provide significant new meaning beyond the already descriptive schema parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes an onboarding questionnaire email for new clients after contract signing, listing specific items gathered. It distinguishes from sibling tools like client_onboarding_checklist by focusing on an email that collects information, not a checklist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after contract signing but does not explicitly state when to use this tool versus alternative onboarding or email tools. No exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the benefit (future drafts matching voice) but not side effects, storage limits, or overwrite behavior. Partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple saving tool but lacks details like naming conventions, data limits, or editability. Missing elements for full completeness given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have descriptions. The tool-level description adds no extra meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb-resource combination: 'Save a winning proposal as a reference example.' It distinguishes from siblings like draft_proposal or delete_proposal by specifying the action and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after winning a proposal but does not explicitly state when to use this tool vs alternatives or when not to use it. No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It reveals that the tool does not count against draft limits, but it does not clarify whether the email is sent, drafted, or returned as output. This omission leaves the agent uncertain about 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that are front-loaded with the core purpose, followed by a contrast and a unique behavioral trait. No redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should explain what happens after invocation (e.g., draft generated, sent). It fails to do so, leaving a gap in completeness. However, it covers the tool's intent and key differentiator well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema, only briefly mentioning optional fields. No additional constraints or examples are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: write a personal email asking for a testimonial after successful project delivery. It distinguishes from siblings like 'testimonial_follow_up_email' by emphasizing it is a genuine, specific ask, not a form or survey link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies when to use ('after successful project delivery') and contrasts with alternatives ('not a form, not a survey link'). However, it does not explicitly list exclusions or alternative tools by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the email does not count against the monthly draft limit and positions as a strategic partner without hard-selling. However, it does not address other behavioral aspects like destructive actions, authentication needs, or whether the email is sent automatically or returned as text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (few sentences) and well-structured: it states the purpose, lists content components, explains the strategic benefit, and notes a constraint (draft limit). Every sentence contributes valuable information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description provides a good overview of the email's structure and content. It covers the key elements a user needs to know. However, it could be slightly more complete by mentioning that the tool generates draft text (implying the output is the email body) or clarifying whether it saves the draft or returns it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds little extra meaning beyond the schema; it provides usage examples (e.g., comma-separated deliverables) that are already in the schema descriptions. No significant new semantic value is added by the description text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes an end-of-year review email to long-term clients, listing specific content sections (deliverables, result, reflection, suggestion). It distinguishes itself from transactional vendor emails, and among siblings like 'client_anniversary_email' or 'retainer_check_in_email', this tool's focus on annual review and strategic positioning is unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates use for end-of-year or end-of-engagement periods with long-term clients, and mentions it opens renewal discussions. However, it does not explicitly state when not to use this tool or provide direct alternatives among the many sibling email tools, leading to some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the draft limit exemption but fails to disclose whether the tool is read-only or has other side effects, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a single note. It is front-loaded with the core action and adds valuable context about output format and draft limits without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and moderate complexity, the description provides sufficient context about the output (challenge, approach, results, learnings) and the target user (freelancers). It is complete enough for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description lists outline sections like 'learnings' that are not parameters, adding slight context but not enhancing understanding of the actual parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool transforms a completed project into a structured portfolio case study with specific outlined sections. It distinctly differentiates itself from the sibling tools, which are primarily email templates and proposal-related, by focusing on portfolio documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is for turning completed projects into case studies, noting it 'does not count against your monthly draft limit.' While it doesn't provide negative guidance or alternatives, the sibling context makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It explains the tool creates a professional document, requires sign-off, and protects from scope creep. However, it does not disclose what happens after creation (e.g., download, send, store) or any side effects. The behavior is generally safe but lacks 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, front-loading the main action. Every sentence adds value: purpose, content of document, benefit, and note about draft limit. Could be slightly more streamlined, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns. It states it writes a document but doesn't specify format (e.g., text, PDF, download link). Given 6 parameters and the tool's nature, the description covers the input well but leaves output unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond schema: it mentions 'additional cost and timeline impact' which map directly to parameters already well-described in the schema. No significant additional semantics provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing a professional change order document when a client requests work outside the original project scope. It uses specific verbs and resource (change order document) and distinguishes from sibling tools like scope_change_email or scope_clarification_email by focusing on document generation rather than email communication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (when client requests work outside original scope) and mentions it requires client sign-off. However, it does not mention when not to use it or provide alternatives among siblings, such as scope_change_email for simpler notifications. Still, the context is clear enough for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses one behavioral trait (no impact on draft limit) but does not detail output format, whether it actually submits the pitch, or any side effects. The description adds moderate value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) with the main purpose front-loaded. The marketing sentence about public speaking adds context but is not strictly necessary; overall efficient without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description adequately explains what the tool generates and the required inputs. However, it lacks details on the return format or any post-generation steps (e.g., copying to clipboard). It is minimally complete for a generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds minimal extra meaning beyond the parameter descriptions. It reinforces that key_takeaways should be comma-separated but does not provide new semantic context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a speaker submission for conferences, meetups, or podcasts, specifying the output (abstract, takeaways, bio) and format (CFP). This distinguishes it from sibling tools like cold_pitch or linkedin_post, which serve different content generation purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use it—for CFP submissions as a high-authority marketing move—and includes a note about not counting against monthly draft limits. However, it lacks explicit guidance on when not to use it or alternatives (e.g., for non-talk pitches).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool sends an email, includes a scope summary, and asks for confirmation. It also notes it does not count against a monthly draft limit. However, it does not clarify whether the email is actually sent or just drafted, nor does it mention side effects like saving drafts or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and well-structured, starting with purpose, then parameters, then workflow, then a practical note. However, it is somewhat verbose and could be trimmed for conciseness without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers the inputs and their usage, but it lacks information about the output (e.g., whether a draft or sent confirmation is returned). Given no output schema, this gap reduces completeness. It also does not mention error handling or what happens on success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 9 parameters (100% coverage), and the description adds significant value by explaining the purpose of each parameter, providing examples, and specifying which are required versus optional, including how to omit irrelevant ones.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes and sends a confirmation email before work begins, using specific verbs and resource. It distinguishes from sibling tools by placing it in a workflow sequence: after discovery_call_follow_up_email and before project_kickoff_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (before work begins to prevent scope disputes) and includes a workflow diagram that implicitly indicates alternatives. However, it lacks explicit exclusions or 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses the behavioral trait 'Counts against your monthly draft limit', which is useful. However, it does not mention whether the tool modifies an existing proposal, sends the proposal, or requires specific authorization. More detail on side effects would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three sentences. It front-loads the condition and action, then adds value with strategy and policy info. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the use case and trigger well. However, it does not explain what the output is (e.g., a draft proposal text, an email), nor whether the tool sends or saves the proposal. Given no output schema, this gap limits completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional parameter meaning beyond the schema; it only restates the general action. It does not clarify parameter formats or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool writes a revised proposal with reduced scope when a client says the quote is too high. It distinguishes itself from siblings like 'discount_request_response' by explicitly stating 'not a rate cut', and from general proposal tools by the specific trigger scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear trigger condition: 'when a client says your quote is too high'. It implicitly advises against using for rate cuts. However, it does not explicitly mention when not to use or list alternative tools (e.g., 'discount_request_response' for discount requests).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions it doesn't count against draft limit, but does not disclose whether it saves or stores data, or if it has side effects beyond generating text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with main purpose and is reasonably concise at ~160 words, though some phrases like 'prevents scope creep and 'bad brief' problems' could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers use case, timing, and parameters well. However, lacks description of output structure (e.g., format of the questionnaire) despite no output schema, which would help an agent understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The overall description adds context like defaults and format options, but does not provide significant additional meaning beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate a structured client brief questionnaire' with a specific verb and resource, and distinguishes it from sibling tools by clarifying its use at the start of an engagement before proposals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use this at the very start of an engagement — before drafting a proposal or setting a price.' Lacks explicit alternatives but context implies it's for new client onboarding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It adds value by noting 'Does not count against your monthly draft limit', but it does not disclose whether the email is sent or just drafted, or any other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with key information front-loaded: purpose, sibling distinction, tone guidance, and draft limit detail. It is efficient but slightly verbose in the middle.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description covers purpose, usage, tone, and draft limit context. It lacks explicit mention of output format but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not elaborate on parameters beyond what the schema already provides, adding no extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes an email ending a client relationship, specifies the relationship type (retainer, long-term engagement), and explicitly distinguishes from project_closure_email, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context ('for when you are choosing to end the relationship') and names an alternative (project_closure_email). However, it omits exclusions and does not reference other relevant sibling tools like client_decline_email.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It discloses the email's tone ('confident and clear, not apologetic') and that it doesn't count against draft limits, but does not explain whether the email is sent directly or returned as text, nor any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each adding essential information: purpose, tone, timing, flexibility, and a benefit. No wasted words, and the most important info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 8 parameters and no output schema, the description does not explain the return value (presumably email text) or how parameters interact. The detailed parameter schema compensates, but the tool lacks a complete picture for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The tool description adds no additional meaning or usage guidance beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a deposit request email, specifies the timing (before work begins, after contract/SOW), and distinguishes it from other email templates with its unique focus on deposits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool ('fills the gap between signing the contract/SOW and starting work') and notes it works for any deposit amount. However, it does not mention when not to use it or compare to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool reads content, but does not disclose that it is read-only, or describe return format, permissions, or error behavior. However, the behavior is straightforward and the description is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no superfluous information. Purpose is stated first, followed by a direct usage hint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fails to explain what 'full content' means (e.g., format, structure). It also omits error handling or prerequisites beyond listing. It is somewhat incomplete for a tool with one parameter and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so baseline is 3. The description does not add additional meaning beyond what the schema already provides (parameter name and example).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool reads the full content of a saved proposal by filename. It distinguishes from siblings like list_proposals, save_proposal, delete_proposal by specifying the action of reading content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using list_proposals first to see available filenames, which is helpful prerequisite guidance. It does not cover when not to use or alternative tools, but for a simple read tool this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses that the tool does not use a monthly draft limit, but does not detail other behavioral aspects such as whether the email is sent immediately or creates a record.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is roughly 90 words across two paragraphs, with the core purpose in the first sentence. It is well-structured and front-loaded, though a slightly more concise version could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the many similar sibling tools, the description adequately covers the purpose, usage scenarios, and key components of the email. The parameter schema is thorough, and while there is no output schema, the output is a straightforward email.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by listing 'the work, the price, what's included, and a clear next step' but does not significantly enhance understanding beyond the already detailed parameter descriptions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Write a short, confident email sending a price quote or estimate' with a specific verb and resource. It also distinguishes from siblings by noting situations where 'a full formal proposal isn't needed' and adds a unique benefit about not counting against monthly draft limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit scenarios like 'quick projects, hourly work, or a client who just asked 'how much?'' which help the agent decide when to use. It implicitly suggests alternatives (formal proposals) but does not include a clear when-not-to-use list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool acknowledges the referral, expresses appreciation, and may offer to return the favor. It also notes the draft limit benefit. However, it does not clarify whether the tool sends the email or just drafts it, nor any side effects or permissions needed, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each contributing value: purpose, content details, versatility, and a unique benefit. It is front-loaded with the primary function, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description covers the purpose and partial behavior but does not explain the output format (e.g., returns email text, sends it, or saves to drafts). It also lacks prerequisites or error handling. This leaves gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 6 parameters documented in the schema. The description adds no additional parameter-level details beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Write a warm, genuine thank-you email to someone who referred a new client to you', specifying a verb and resource. Among siblings, it is distinct from referral_request (which asks for referrals) and referral_thank_you (possibly a shorter variant), so it is well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use: after a referral, and it works at any project stage. It also notes the tool does not count against draft limits. However, it does not explicitly exclude alternatives or state when not to use it, lacking full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description notes a behavioral trait (not counting against monthly draft limit) and implies a professional tone. However, it does not disclose whether the tool sends the email or merely generates text, nor does it mention required permissions or rate limits beyond draft count. No annotations are present, so the description carries the full burden but misses key 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise and front-loaded. Three sentences cover purpose, content, and a key differentiator. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description should clarify what the tool returns. It implies the email text is generated but does not explicitly state the output format or behavior (e.g., whether it is saved, sent, or only returned). The description adequately covers the input scenario but leaves the output ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the email's overall structure and tone (professional, non-accusatory, options-oriented). While it does not detail each parameter's role in the email, the schema already provides good per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: writing a professional email about scope growth. It specifies the audience (client), trigger (work beyond original scope), and content (raises issue, outlines impact, presents options). This differentiates it from siblings like 'scope_clarification_email' (clarifying scope) and 'scope_warning_email' (warning about creep) by focusing on post-growth resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description tells when to use (scope growth) but does not explicitly say when not to use or mention alternatives. While the scenario is clear, there is no direct comparison to similar tools like 'change_order' or 'scope_clarification_email', leaving the agent to infer usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it extracts signals and suggests questions, implying a read-only analysis. However, it does not explicitly confirm it is non-destructive or describe any side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence states the action and outputs, the second provides usage guidance. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description gives a concrete list of extracted items (budget signals, timeline urgency, etc.) and suggests clarifying questions, giving a clear picture of what the output will contain. This is sufficient for understanding the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'brief' described as 'The client brief, job post, or email thread to analyze'. The description adds context about what the analysis extracts but does not add new parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes a client brief before drafting, listing specific outputs like budget signals, timeline urgency, red flags, and clarifying questions. It distinguishes from sibling tools which are mostly email drafting and sending tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool first when a brief is vague or budget unclear, providing clear context for when to use. It does not explicitly mention alternatives or when not to use, but the guidance is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It describes the tone (confident, not desperate) and the fact it doesn't count against draft limits. However, it lacks details on output (draft vs send), authentication requirements, or rate limits. The behavioral disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it leads with purpose, contextualizes the value, gives tone guidance, then lists parameters. Every sentence is necessary and adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-param tool without output schema or annotations, the description covers purpose, tone, parameter details, and a limit note. It is missing explicit description of the output (e.g., the generated email text). This is a minor gap but overall complete enough for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by grouping parameters as required/optional and providing examples (e.g., availability_window examples). However, it mostly reiterates the schema descriptions without adding significant new semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a short, warm email to past clients/contacts announcing availability. It distinguishes from siblings like annual_review_email or bid_lost_follow_up by focusing on availability announcement. The high-ROI context further clarifies its specific use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (when you have upcoming availability) and notes it's high-ROI. It mentions it does not count against monthly draft limit. However, it does not explicitly exclude scenarios or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes email content and tone but does not explicitly state whether the tool sends the email or just generates draft. Ambiguous about saving vs outputting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with main purpose. Efficiently conveys core info without fluff. Slightly verbose in some phrases but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides good usage context and distinction from sibling, but lacks output format details (plain text, subject line, etc.) since no output schema. Does not clarify save/send behavior, leaving gaps for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed param descriptions. The tool description adds overall context (tone, word limit) but does not significantly enhance parameter understanding. Baseline 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it writes a short proactive check-in email during long projects, distinguishes from project_status_update (light vs full report), and specifies word limit and purpose. Clear verb+resource with sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (mid-phase, silent execution periods), when not to (not a full weekly report), and mentions draft limit policy. Directs to project_status_update for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description reveals that the tool is a non-destructive generation tool (does not count against draft limit) and produces structured output. It does not disclose any side effects, permissions, or rate limits, but the generative nature is conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences that cover purpose, inputs, outputs, workflow position, and a key behavioral note. Every word adds value, making it easy for an AI agent to quickly understand the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema), the description provides sufficient context: what it generates, its place in a workflow, and a non-standard feature (no draft limit). It could be more complete by specifying the output format, but the listed outputs (questions, agenda, confirmation items) are clear enough for an agent to expect appropriate results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are described in the input schema with clear descriptions (brief, analysis, your_service). The description adds a usage hint for analysis and your_service but does not add significant new semantic detail beyond what the schema provides. With 100% schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: preparing for a discovery call. It specifies the input (brief) and the generated outputs (sharp questions, call agenda, confirmation items). It also positions the tool in the workflow between analyze_brief and draft_proposal, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Use between analyze_brief and draft_proposal') and notes that it does not count against the monthly draft limit, which is helpful for resource planning. It lacks explicit 'when not to use' guidance, but the context provides a clear usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states 'load into library' without clarifying whether it is destructive, idempotent, or if repeated runs cause issues. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and followed by usage guidance. No superfluous words; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a simple action, the description adequately covers purpose and when to use. It lacks details on the nature of the examples or repeated behavior, but is largely complete for a setup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. The description does not need to add parameter info, and the baseline of 4 is appropriate for a param-less tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads bundled example proposals into the user's library for use as style references. It differentiates from siblings by being a setup tool, and the verb 'load' specifies the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to run on first use to get started without needing past proposals. This provides clear when-to-use guidance, though it does not specify when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: tone (calm, friendly, no guilt-tripping), length (under 80 words), and a notable effect (often gets reply). Also mentions it doesn't count against monthly draft limit. No contradictory or missing key traits for an email tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences covering purpose, benefit, and constraints. Front-loaded with the action verb and resource. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple email generation tool with no output schema and complete parameter descriptions, the description adequately explains context, tone, and effect. Could mention whether the email is drafted or sent, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. The description does not add new parameter-specific meaning beyond what the schema already provides, thus no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's for writing a 'just closing the loop' email to a prospect who has gone dark after follow-ups. It distinguishes from other email tools by emphasizing the counter-intuitive effect and tone, but could more explicitly differentiate from similar sibling tools like reactivation_email or win_back_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (prospect gone dark after follow-ups) and includes a strong rationale for use. However, lacks explicit when-not-to-use guidance or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool 'generates' a pitch, implying it is a content generation tool, but does not disclose whether it sends emails, saves drafts, or has side effects. The behavioral traits are partially covered but lack completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 80 words, with a clear structure: purpose, context, differentiation, and a notable fact (draft limit). Every sentence adds value, though it could be slightly more efficient without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the purpose and strategy well, but it lacks specification of what the tool returns (e.g., full email text, subject line). Given the absence of an output schema and moderate complexity, the description is sufficient but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The main description adds strategic context that indirectly helps understand parameter usage, but it does not provide additional meaning beyond the schema descriptions for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Write' and resource 'cold pitch to appear as a guest on a podcast', clearly stating the tool's function. It explicitly distinguishes itself from sibling tools 'conference_talk_pitch' and 'cold_pitch', ensuring no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for podcast guest pitches), provides context on why generic pitches fail, and explicitly contrasts with alternative tools. It also mentions that it does not count against monthly draft limits, offering additional usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions that the tool does not count against the draft limit and requires certain parameters. It does not disclose behavioral traits like whether it sends the email automatically, any required authentication, or what happens on the server side. For a tool that generates email content, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise with a clear purpose statement upfront. The parameter list is somewhat lengthy but well-structured with 'Required:', 'Optional:' and inline examples. A minor improvement could be to trim example verbosity, but overall it's well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 2 required, no output schema, the description covers the tool's function and parameter usage adequately. It explains the email's purpose and bridges the gap between verbal and formal agreement. It could mention the output format (e.g., 'returns the email body'), but since there is no output schema, the current level is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all 7 parameters described. The description adds significant value beyond the schema by providing example values (e.g., 'kick off Monday June 23'), notes on when to omit, and synonyms (e.g., 'brief bullet list'). This helps the agent fill parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing an email to confirm project scope before a formal contract. It uses specific verb 'confirm' and resource 'email', and distinguishes from siblings like 'scope_clarification_email' or 'contract_sent_email' by specifying the timing ('before the formal contract arrives').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: 'when you want to confirm a client's project scope before the formal contract arrives.' It also notes that it doesn't count against the monthly draft limit. However, it lacks explicit when-not-to-use or alternative tools, though the context of sibling names provides some differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates the tool generates a professional email and a notable behavioral trait: it does not count against the monthly draft limit. This gives agents useful execution guidance. However, it does not detail any side effects or limitations beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences plus a brief note about the draft limit. It immediately communicates the main purpose and includes the most critical information without any filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a text generation tool with no output schema and well-documented parameters, the description is nearly complete. It explains the purpose, tone, and a key constraint (draft limit). Minor omission: it does not mention whether the email includes a subject line or the exact format, but that is often inferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are already documented in the input schema. The description itself adds no additional parameter-level details, so it meets the baseline expectation but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Write an email') and the specific context ('telling an existing client you are raising your rates'). It distinguishes itself by emphasizing the freelancer context and the sensitive nature, which sets it apart from similar tools like price_increase_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context (freelancers, anxiety-inducing task) and a unique benefit ('Does not count against your monthly draft limit'), but it does not explicitly state when to use this tool over alternatives like price_increase_email, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the tool does not count against monthly draft limit, a useful behavioral trait, but does not explain whether the email is automatically sent, saved as draft, or just generated. More behavioral details (e.g., required permissions, action after generation) would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief yet comprehensive, using a bullet list for key points. Every sentence adds value, no redundancy. It front-loads the purpose and then lists covered items efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters (3 required) and no output schema, the description explains the core functionality, covered topics, and a key behavioral note (draft limit). It does not describe the output format or how the generated email is used, but it is reasonably complete for a generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter. The description adds context like defaults and optional behavior (e.g., 'If omitted, a generic description is used'), but this is marginal improvement over the schema. Baseline is 3 due to full coverage, and description adds some value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Write a professional email') and resource ('retainer proposal'), clearly distinguishing it from sibling tools by focusing on converting a one-off engagement into a retainer. It lists covered aspects, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use (convert one-off to retainer) and what it covers (scope, hours, fee, rollover, notice period). It also notes it doesn't count against draft limit. However, it doesn't explicitly mention when not to use or direct to alternatives, though the sibling context is extensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions the tool does not count against monthly draft limit and explains route behaviors. However, does not disclose output format, potential side effects, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is efficient and well-structured. It opens with purpose, explains the common problem, then lists three routes with brief rationale, ending with a benefit and a note about draft limits. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains the tool's logic and parameter usage. It covers the email generation intent and route options. Minor gap: does not specify expected output format (e.g., subject line, salutation) but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline 3 is appropriate. Description adds context (e.g., scope_item should be concrete, route explanations) but does not significantly exceed schema-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool writes a professional email responding to out-of-scope requests. It specifies three handling routes (quote, decline, include_once), distinguishing it from siblings like scope_creep_email or scope_change_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes common scenario (freelancers mishandling scope creep) and when each route is appropriate. Provides contextual guidance but lacks explicit when-not-to-use or direct comparison with similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the output structure (deliverables, timeline, etc.) and states it's ready to paste into a contract. However, it does not disclose whether the tool is read-only, permissions needed, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence communicates purpose, second lists output contents. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value structure (deliverables, timeline, etc.) and how it will be used (paste into contract or send to client). Missing details like format (e.g., Markdown) are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description adds context that the proposal is 'accepted' but does not enhance parameter meaning beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate' and resource 'Scope of Work document', specifying input 'from an accepted proposal' and listing deliverables. It distinguishes itself from sibling tools like 'contract_template' and 'change_order' by focusing on a structured SOW derived from an accepted proposal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after proposal acceptance ('from an accepted proposal') but does not explicitly state when to avoid using this tool or mention alternatives. The context is clear, but no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses tone ('warm, non-pushy') and a behavioral note ('does not count against your monthly draft limit'). No mention of authorization or destructive actions, but the tool is straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with clear structure: purpose, context/statistic, timing/exception. Every sentence is necessary and well-placed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers use case, timing, and a behavioral trait. No output schema, but email writing tools typically don't need that. Sufficient for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond schema, e.g., clarifying that 'value_hook' makes the upsell relevant. No parameter format or constraints are added beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Write a warm, non-pushy email'), the audience ('a happy client'), and the context ('after a successful project'). It distinguishes from siblings like cold_pitch or project_completion_email by emphasizing existing client upsell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('right after delivering and getting positive feedback') and highlights high ROI. Does not explicitly mention alternatives or when not to use, but the context signals are clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions the tool generates an email, explains the routes, and notes it does not count against a draft limit. However, it doesn't disclose that the output is a draft requiring user action, or describe any side effects, which would be helpful for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: purpose first, then routes, then parameters. Every sentence adds value. Minor redundancy exists in repeating the three routes in both the overview and parameter section, but overall it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, multiple routes, and no output schema, the description covers purpose, usage guidelines, parameter semantics, and a behavioral note (draft limit). It lacks an explicit statement about the output format (a draft email), but the tool's nature is well implied. It is sufficiently complete for an AI agent to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining how each parameter maps to the three routes (e.g., what_went_wrong for acknowledge, your_response for dispute), integrating them into the usage narrative beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('write a professional email responding') and clearly identifies the resource (client complaint email). It distinguishes from creative feedback, which is a sibling tool, and outlines three distinct routes (acknowledge, dispute, resolve), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (client complaint/serious dissatisfaction) and distinguishes from creative feedback. Provides context on the three routes with default recommendation. However, it could be more explicit about specific scenarios where other sibling tools are preferred over this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description goes beyond annotations (none provided) by stating the output is short, non-pushy, and designed to reopen conversation. Does not mention side effects or limitations, but tone and intent are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. Front-loaded with purpose, then behavioral promise, then input requirements. Efficient and easy to grasp.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers purpose and inputs, it does not specify the output format or how the generated message is returned. For a generating tool, this is a missing detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description repeats the need to provide summary and days. No additional meaning beyond schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool writes a follow-up message for a proposal with no response, using specific verb-resource combo. It stands out from siblings like `proposal_to_email` or `contract_unsigned_follow_up` which handle different scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to provide proposal summary and days since sent, giving clear context for use. However, no guidance on when not to use or comparison to alternative tools like `bid_lost_follow_up`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses an important cost behavior: 'Does not count against your monthly draft limit.' This is a valuable behavioral trait beyond the standard generative function. No contradictions with annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a distinct purpose: what it does, how it adapts, when to use, and a behavioral note. No wasted words, front-loaded with core function. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main function, adaptation, and timing, but lacks details on output format (e.g., bulleted list, plain text) and edge cases. Given no output schema, a brief format hint would improve completeness for an agent to expect the response type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The description reinforces that the checklist adapts by project_type and is tailored, but adds no new constraints or format details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Generate' and the resource 'tailored list of everything you need from a client', specifying it adapts by project type. This distinguishes it from sibling tools that send emails or proposals, as it focuses on creating an actionable checklist for client onboarding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit instruction: 'Send this after the kickoff email, before starting work.' This provides clear context for when to use the tool, but does not mention specific alternatives or when not to use it, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It explains that the email 'makes the ask easy: it gives context on the prospect, sets expectations on time commitment, and makes it simple to say yes or no'. It also notes the draft limit exemption. However, it does not disclose any authentication requirements, whether the email is sent automatically, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently front-loads the core purpose, then adds differentiation, context, and a key behavioral note (draft limit). It is concise without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains what the email does and its context. It sets expectations for what the tool produces (an email that includes context, time commitment, and an easy yes/no). It is sufficient for an agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add parameter-specific meaning beyond the schema, but the schema descriptions themselves are detailed. The overall description provides context but not parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's verb and resource: 'Ask a trusted past client to be a named reference for a specific prospect'. It immediately distinguishes from three sibling tools (testimonial_request, recommendation_request_email, referral_request) by contrasting their purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly compares to alternative tools and provides context on when to use each. Also notes that the tool 'does not count against your monthly draft limit', providing a practical rule for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the post is concise, authentic, 150–250 words, includes hook/story/takeaway/CTA, and does not count against draft limits. No destructive behavior, but transparent about generation characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with additional detail about word count and structure. It is front-loaded with purpose and context, concise without being overly terse. Minor room for tightening.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description explains the output format (150–250 word post with specific structure) and usage context. It does not explicitly state return type but is adequate for a generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add new parameter details beyond the schema, but it provides context for the tool's purpose. The schema already explains each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a LinkedIn post, specifies the content types (project win, lesson learned, professional insight), and distinguishes it from sibling tools (none other for LinkedIn posts). It also mentions it does not count against monthly draft limit, adding clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (for LinkedIn posts about professional insights) and why (to get inbound leads), but does not explicitly mention when not to use it or compare to alternative tools. However, the context is clear enough for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses tone ('personal and considered, not a mass newsletter blast'), workflow (individual sending), and a constraint ('does not count against your monthly draft limit'). It also clarifies optional parameter usage for personalization. This is strong behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is several sentences but each sentence adds value: purpose, tone distinction, workflow, parameter notes. It is front-loaded with the core purpose. Slightly verbose but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers purpose, tone, workflow, and parameter guidance thoroughly. It provides enough context for an agent to use the tool appropriately. Minor gaps: no mention of expected response or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have schema descriptions (100% coverage), so the schema already defines each parameter. The description adds only light context (e.g., 'optional: why relevant...') but doesn't provide new semantic insight beyond what the schema offers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing a personal announcement email to an existing client about a new service. It specifies the relationship context and goal ('let trusted clients hear first'), distinguishing it from cold outreach or mass newsletters. The verb 'write' and resource 'announcement email' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'warmer than cold outreach because you already have a relationship,' indicating when to use it (existing clients) and contrasting with cold pitches. It also provides workflow guidance ('draft here → send individually'). However, it does not list specific alternative tools or scenarios to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool does not count against monthly draft limits and mentions the tone. However, it does not describe the output format, side effects, or any limitations beyond that. Adequate for a non-destructive email generation tool, but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that starts with the core purpose, then lists scenarios and parameters. It is well-organized and informative, though slightly lengthy. Every sentence adds value, but could be tightened slightly without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 params, no output schema), the description covers the tool's purpose, scenarios, parameter guidance, and a behavioral note (draft limit). Missing is any description of what the output (the email) looks like or how it is returned. Overall fairly complete for an email generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 9 parameters have descriptions in the schema (100% coverage). The description adds value by explaining the three scenario options, the purpose of reason with examples, and contextualizes parameters like current_rate and project_name. This enriches the schema descriptions, making parameter selection more intuitive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a confident, non-apologetic email for rate increases. It distinguishes itself from sibling tools like 'rate_increase_email' by specifying three scenarios and tone, making its unique purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed guidance on three scenarios (advance_notice, retainer_renewal, mid_project) with context on when each is appropriate. Notes that mid_project is rare and requires justification. Does not explicitly state when not to use the tool or mention alternatives, but the context is clear for the intended use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes output as a professional email draft, mentions no side effects, and clarifies it does not count against draft limit. Does not explicitly state it does not send the email, but tone implies generation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear opening, route explanations, and parameter details. Every sentence adds value; minor motivational language could be trimmed but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately conveys what the tool returns (an email draft). Minor gap: does not specify output format (plain text, HTML) or if it's a full email with headers. Sufficient for an AI to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds significant value by explaining each parameter's purpose and tone (e.g., reason should be brief and factual, route descriptions). Goes beyond simple schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it writes a professional email for missed deadlines, with three distinct routes. Differentiates from siblings like 'late_delivery_apology' by specifying early_warning, on_deadline, already_late options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to send (early, on deadline, already late) but does not explicitly compare to alternative tools or state when not to use this tool. Implied usage but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It notes the email should be under 100 words and doesn't count against monthly draft limits. However, it doesn't disclose whether the email is drafted or sent automatically, or any authorization needs. Adequate but could be richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences with no wasted words. Each sentence adds value: defines purpose, tone, comparison to alternatives, length constraint, and a non-obvious feature (no draft count). Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple email generation task and detailed parameter schema, the description fully covers the use case, tone, length, and unique value. No output schema needed because output is clearly an email draft.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 5 parameters with 100% coverage. The description adds minimal extra meaning beyond restating the value_add parameter's purpose. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a short, light-touch email to a prospect who went quiet mid-conversation. It distinguishes from siblings by contrasting with 'cold leads die or over-chase awkwardly' and specifies the target: warm lead, not needy or pushy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use: for warm leads that stalled before committing. It implicitly warns against using for cold leads or aggressive tones, but does not explicitly mention alternative tools like win_back_email or cold_pitch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that the tool does not count against the monthly draft limit, a useful billing behavior. However, it does not describe other behavioral traits such as AI generation, storage, or read/write nature, which limits 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each contributing distinct information: clear purpose, differentiation from inbound, stylistic guidance, and billing note. No redundancy or filler, achieving high conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple text generation tool with 6 parameters and no output schema, the description covers the essential usage context. It could mention the output format (a draft email) but the name and description make that obvious. It is adequately complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by noting that the 'ask' parameter defaults to 'a 15-minute call' and provides stylistic guidance for the overall email. This extra context lifts the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Write a cold outbound pitch email' and identifies the resource as a potential client who hasn't contacted you. It explicitly distinguishes from 'inbound proposal work' and sibling tools like 'cold_pitch_follow_up', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the tool (for proactive business development to non-contact clients) and contrasts it with inbound proposals. It also provides stylistic guidance (short, specific, single easy ask) and a billing hint (doesn't count against draft limit). It lacks explicit 'when not to use' but is sufficient for clear usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses that it uses saved winning proposals as references and mentions rate limits (free plan: 5 drafts/month). However, it doesn't specify if the proposal is automatically saved or how output is delivered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. First sentence states purpose, second adds context, third mentions limits. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description says 'Returns a ready-to-send proposal', which is sufficient for an agent to understand the result. Lacks details on output format or how to access the proposal, but overall context is adequate given the simple parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented. Description adds no additional meaning beyond the schema; it mentions 'brief' but doesn't elaborate on budget, deadline, your_rate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool drafts a proposal from a brief using saved winning proposals as style references, distinguishing it from siblings like analyze_brief (analysis only) and budget_proposal (budget-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies when to use (when you have a brief and want a proposal) and mentions style references, but lacks explicit exclusions or alternatives like 'use analyze_brief if you only need analysis'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the email is short and genuine, asks for honest input, and notes it does not count against the monthly draft limit. While it could mention delivery method or timing, it adequately communicates the tool's non-destructive behavior and purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states purpose and scope, second adds benefit, third distinguishes from sibling and adds a constraint. Every sentence earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description covers purpose, usage context, and a key behavioral trait. It doesn't explain delivery or confirmation, but for a simple email generation tool, it provides sufficient information for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters. The description adds context (e.g., optional specific_aspect makes the request purposeful), but does not significantly extend beyond the schema. Baseline 3 is appropriate since the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a feedback request email after a project, emphasizing it is for private feedback, not a public testimonial. It uses a specific verb ('write') and resource ('email'), and explicitly distinguishes from the sibling 'testimonial_request' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use (after a project, for private feedback) and contrasts with testimonial_request for public reviews. It could be improved by explicitly stating scenarios where this tool should not be used, but the sibling differentiation provides strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It notes that the tool 'does not count against your monthly draft limit', which is helpful. However, it does not mention read-only nature, output format, or other side effects beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each providing distinct information: action and output, specific improvements, and usage guidance with a behavioral note. No redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and no output schema, the description covers purpose, usage, and a behavioral trait. It could mention the output format or idempotency, but it is sufficiently complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions, so baseline is 3. The description adds value by stating that if 'focus' is omitted, a full review is given, which goes beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Review' and the resource 'proposal draft', specifies what it surfaces (weak sections, unclear pricing, etc.), and distinguishes itself from siblings like 'draft_proposal' by noting it is meant to be run after drafting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Run after draft_proposal or on any proposal you're about to send', giving clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives beyond draft_proposal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses behavioral traits: the tone ('firm but not hostile'), the variant behavior, and importantly that it 'does not count against your monthly draft limit'. This sufficiently conveys the non-destructive, consumption-neutral nature of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus a short final note. It is front-loaded with the purpose, efficiently describes the variant, distinguishes from siblings, and adds a behavioral note. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a content-generation tool with 8 parameters (all described in schema) and no output schema, the description adequately covers the scenario, variant, and a consumption behavior. It lacks explicit mention of the return value (the drafted email), but that is implied. Overall complete given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what the schema already provides for each parameter. It gives overall context for the tool's output but no parameter-level enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'write', the resource 'overdue-payment reminder', and the condition 'when a client has not paid an invoice by the due date'. It also explicitly distinguishes the tool from two sibling tools: invoice_cover_email and deposit_request_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use the tool ('when a client has not paid an invoice by the due date') and describes the second-reminder variant. However, it does not explicitly state when not to use it, nor does it mention other alternatives beyond the two siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the content of the email but does not disclose if the tool sends the email, drafts it, or returns text. Lacks details on side effects or return format, though it implies a writing action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a purpose: main action, key elements, sibling differentiation, and a usage note. Front-loaded and efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (8 parameters, no output schema), the description explains purpose, content, and alternatives. It is nearly complete but could specify the return type (email text) and whether it sends the email.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The tool description adds context about overall email structure but does not significantly enhance meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes a professional response for mid-engagement cancellation, listing specific content like acknowledgment, work summary, kill fee, and final invoice. It also distinguishes from four sibling tools, providing a precise purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (client cancels mid-engagement) and distinguishes from sibling tools with specific names and brief explanations. Also notes that it does not count against a monthly draft limit, adding practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully cover behavior. It describes the email content and purpose but does not disclose whether the email is sent immediately or saved as a draft, nor any side effects like logging. Behavior is somewhat implied but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with no redundant elements. The first sentence front-loads the purpose, followed by details and sibling differentiation. Every sentence adds value without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description covers purpose, usage, and content well. It is sufficient for an agent to understand the tool's role. Minor gaps (e.g., whether the email is sent or drafted) prevent a perfect score, but for a straightforward email generation tool, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The overall description adds context about the email's structure but does not provide additional meaning beyond what the schema already offers for individual parameters. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Write the email sent when delivering a project milestone or phase' with a specific verb and resource. It explicitly distinguishes from sibling tools 'project_completion_email' and 'project_status_update', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use (delivering a milestone/phase, not final delivery) and names alternative tools for other cases. Also adds a unique note about not counting against monthly draft limits, giving practical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It notes the tool does not count against draft limit, but does not disclose other behavioral traits such as whether it sends immediately, requires authentication, or is destructive. Some transparency is present but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with no wasted words. It front-loads the purpose, provides tone guidance, usage context, and a clear differentiator. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters (4 required) and no output schema, the description provides adequate context: it explains the email's purpose, tone, timing, and differentiator. It covers the essential aspects, though it could mention sending mechanism or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a description. The tool description adds overall tone and usage context but does not provide additional per-parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional heads-up email before leave, explicitly distinguishing it from an auto-reply. It uses a specific verb ('write') and resource ('heads-up email') and provides enough context to differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: proactive note to active clients a few days before leave. It distinguishes from auto-reply and mentions that it does not count against monthly draft limit, providing clear guidance on usage and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions unusual traits like word limit and draft limit, not what the tool actually outputs or whether it sends the email.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus a short note on constraints, all front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple email writing tool, the description covers purpose, constraints, and parameter roles, though it lacks explicit output description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds context for parameters like next_step by relating it to signaling next steps, providing value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a short professional email acknowledging receipt of a client payment, distinguishing it from sibling tools like payment reminders or invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies use when payment is received and closes the loop, but does not explicitly exclude alternatives like reminders or follow-ups, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It discloses the action (writes a closing email) and adds a useful behavioral trait ("Does not count against your monthly draft limit"). No contradictions or missing critical safety info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the tool's purpose and behavior for a simple email generation tool. It does not describe the return value (the email text), but that is implicit. Could mention that it generates a draft.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds context about the email's purpose but does not provide additional detail beyond what the schema already states for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ("Write the final email") and resource ("project closure email"), lists the content elements (confirms delivery, handover, thanks, future work), and explicitly distinguishes from the sibling project_kickoff_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states when to use ("when a project is fully delivered and complete") and differentiates from project_kickoff_email. However, it does not mention other related siblings like project_completion_email or project_handover_email.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It discloses that the tool 'does not count against your monthly draft limit,' which is a key behavioral detail. It doesn't mention automation or permissions, but the core behavior (generating an email) is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a few sentences that front-load the purpose and quickly list key components. No wasted words, easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (3 required), no output schema, and no annotations, the description covers the essential context: what the email contains, optional elements, and a notable behavioral detail. It does not address return values or error states, but for a simple email tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. The description adds no additional parameter details beyond the schema; it focuses on overall purpose. No extra semantic value provided for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly describes the tool's purpose: writing a professional email when delivering final project output and closing out a project. It specifies contents like confirming deliverables, thanks, optional testimonial and future work, distinguishing it from related tools like milestone_delivered_email or project_closure_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to use (final delivery and closure) and what the email includes. While it doesn't explicitly list when not to use or name alternatives, the context is fairly clear given the sibling list. A slight gap in explicit usage boundaries prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses tone requirements and the 'does not count against monthly draft limit' behavior, but it does not clarify what the tool actually outputs (e.g., returns email text, drafts, or sends) or what side effects occur. This missing information leaves ambiguity about tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured: purpose first, then tone guidance, modes, sibling distinction, and parameters. Every sentence adds value, but it could be slightly more concise without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does and how to use it, but it fails to explain what the tool returns or the side effects (e.g., sending vs. generating text). Given no output schema, this is a notable gap. It omits error conditions or authorization needs, which are less critical but still relevant for a tool with 6 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema descriptions: e.g., for 'enquiry_summary' it provides examples, for 'qualifying_questions' it explains format and usage, and for 'response_mode' it clarifies decision logic. This extra context improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional reply to an inbound project inquiry. It specifies the verb ('write'), resource ('professional reply'), and context ('inbound project inquiry from a potential client'). It also distinguishes from siblings by naming specific alternative tools (cold_pitch, client_followup, discovery_call_follow_up_email).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'the email you send when someone reaches out asking if you're available for work.' It provides two modes (reply_and_qualify and reply_and_book) with explicit guidance on when to use each, and it excludes scenarios covered by sibling tools via the 'Distinct from' clause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds the behavioral trait that it does not count against the monthly draft limit. It also describes the output style (short, gracious, memorable) but could be more explicit about safety or side effects. However, it is sufficient for a generative writing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences. The first clearly states the purpose, and the second adds valuable nuance and a perk (draft limit). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the tool's purpose and output style (short, gracious). Since there is no output schema, the description compensates by describing the tone. It is complete enough for the tool's complexity, though it could briefly differentiate from the many sibling email tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for all 5 parameters. The description does not add significant additional meaning beyond what the schema already states, such as the effect of 'keep_door_open' which is documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional response to a client who chose another provider. It specifies the tone (gracious, not bitter) and distinguishes it from similar siblings like 'bid_lost_follow_up' or 'client_decline_email' by emphasizing keeping the door open.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (when a client has chosen another provider) and implies the context. It does not explicitly list alternatives or when not to use, but the context is clear enough for an AI agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that the output is a short, confidence-building email with 2–4 questions, and explicitly states it does not count against the monthly draft limit. This gives useful behavioral context beyond a simple 'write email' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place. First sentence states the primary function, second provides context, third describes the output, fourth adds a behavioral benefit. No fluff and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple email generation tool with no output schema, the description sufficiently covers the input purpose and output nature (short email with targeted questions). It doesn't detail the exact email format, but that's acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds value by explaining how `missing_info` should be formatted (e.g., 'budget range, number of pages') and that `context` is optional but shows attentiveness. This extends the schema's documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool writes a professional email to request missing info before quoting. It contrasts with alternatives ('guessing' or 'sending demands'), which distinguishes its purpose from sibling tools that may serve different email needs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: when you need info before quoting. However, there is no explicit guidance on when not to use this tool or how it differs from other email tools in the sibling list (e.g., brief_confirmation_email, scope_change_email). Adding a 'use this when... not when...' would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool writes an email and does not count against the draft limit, but lacks details on side effects, permissions, or technical behavior. More context on whether it drafts or sends would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the tool's purpose. Every sentence adds value, including the distinction from change_order and the note about draft limits. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple email generation tool with no output schema, the description covers purpose and usage well. However, it does not mention what the output (draft email) looks like or if it's automatically sent. Slightly incomplete given the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description does not add significant meaning beyond the schema descriptions; it only generally references scope creep without detailing parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional email flagging scope creep before a change order, with a specific verb and resource. It distinguishes itself from the sibling 'change_order' by noting that this is the conversation that comes first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when you notice a client requesting something beyond the original brief') and when not ('Different from change_order'). Also explains the collaborative goal, providing clear context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden. It discloses the email's tone ('warm, non-desperate') and that it doesn't count against draft limits, but lacks details on potential constraints like rate limits or dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy: first sentence defines the action, second provides rationale, third specifies constraints. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose, audience, tone, word limit, nature of the ask, and billing exclusion. No output schema is needed given the straightforward email generation task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The tool description adds value by providing context on tone, word limit, and audience, which goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an email to past clients about available capacity. It uses specific verbs ('Write') and resources ('email to past clients'), and is distinct from sibling tools like 'cold_pitch' or 'reactivation_email'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises use for past clients rather than cold pitching, providing context on when to use it. It mentions constraints like 'Under 120 words, one soft ask' and 'Does not count against your monthly draft limit', but does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds valuable behavioral context: the email is warm and respectful, preserves relationships, and does not count against monthly draft limit. It implies the tool generates a draft rather than sending it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, with the core purpose front-loaded. Each sentence adds value, though some minor redundancy (e.g., 'warm and respectful' repeated) could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description covers essential aspects: purpose, scenarios, tone, optional referral, and draft limit. It does not explicitly state the output format (e.g., plain text), but the overall context is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description enriches parameter meaning by explaining the four decline reasons (capacity, not_fit, timing, budget) and the optional referral, adding context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional email declining a client project inquiry, covering four specific situations (capacity, not_fit, timing, budget). It distinguishes from sibling tools that handle other email types (e.g., bid_lost_follow_up, client_followup).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: when you can't or shouldn't take work, with scenarios listed. It implicitly indicates not to use for other purposes, but lacks explicit exclusions or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It details the three modes, their appropriate contexts, and behaviors to avoid. It also notes that the tool does not count against the monthly draft limit. Missing info on authentication or side effects, but these are less critical for a drafting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but front-loads the purpose and key modes. Every sentence adds value, though it could be more structured with bullet points. It's not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three modes, 8 parameters), the description covers behavioral guidance, parameter semantics, and a note on draft limits. No output schema exists, so the description adequately implies the output (a drafted reply). It addresses likely agent confusion about which mode to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose and nuance of each mode, giving examples for differentiator, and clarifying how optional parameters affect output (e.g., omitting competitor_name keeps reply vague). This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it writes a professional reply when a client compares prices. This clearly differentiates it from sibling tools like discount_request_response or bid_lost_follow_up by targeting a specific scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each of the three response modes and when not to (e.g., 'do not use just to close a deal' for match_with_context). It also clarifies what behaviors are avoided (caving, defensiveness). However, it does not explicitly mention alternative tools for related scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool generates a full working contract in plain English and specifies it does not count against a draft limit. It does not detail any destructive effects or authentication needs, but the generation behavior is sufficiently clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, followed by differentiation and suitability. Every sentence adds value without redundancy. It is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description adequately explains what the tool produces (a complete contract) and covers its main features. Given the parameter richness and sibling context, the description is complete enough for an agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 8 parameters, with clear descriptions for each. The tool's description does not add additional meaning beyond listing some contract areas, which are already implied by the parameter descriptions. Thus, baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a 'Freelance Services Agreement' and lists the areas it covers (services, payment, IP, revisions, termination, liability). It distinguishes itself from sibling tools by noting it is more comprehensive than an NDA and more legally framed than a SOW.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use this tool (standard freelance/consulting engagements) and contrasts it with related tools (NDA, SOW). It also mentions it does not count against a monthly draft limit. However, it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool's behavior: it writes an email, has three modes, and does not count against a monthly draft limit. It does not mention auth requirements or rate limits, but those are unlikely for a text generation tool. The behavioral context is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the main purpose, then detailing modes, required/optional params, and tone advice. It is slightly lengthy but every sentence adds value. A 5 would require more conciseness without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 3 modes, and no output schema, the description is quite complete: it covers all parameters with examples and defaults, explains the three modes, and provides professional best practices. It does not describe the return format, but that is implicitly the email text. A 5 would require more explicit handling of edge cases or output specification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the reason parameter's enum values, giving examples for engagement_description and handover_note, and clarifying defaults (reason defaults to natural_end). This extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional email to end a client relationship or retainer, and distinguishes three specific modes (natural_end, capacity, fit_mismatch) with distinct use cases. This makes the purpose highly specific and differentiates it from sibling tools like client_check_in_email or project_pause_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each mode (natural_end for completed projects, capacity for lack of room, fit_mismatch for poor fit) and offers tone advice. However, it does not explicitly state when not to use this tool or mention alternatives from the sibling list, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool generates an email, has three modes with a default, and that certain parameters are mode-specific. It also notes it does not count against a monthly draft limit. Behavioral traits are well-covered, though it doesn't explicitly state it's a non-destructive read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise and front-loaded with the main purpose. Each sentence adds value, covering modes, usage, and parameter guidance. Minor redundancy (e.g., 'the hardest part...') could be trimmed, but overall it is well-structured and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three modes, six parameters, no output schema), the description covers the essential aspects: required/optional parameters, mode behavior, parameter conditions, and differentiation from sibling. It doesn't explicitly describe the output format, but given no output schema, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining usage context for each parameter (e.g., your_conditions used only in counter mode), clarifying the default for response_mode, and providing practical examples. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing a professional response to non-cash payment proposals. It specifies the verb (write a response), resource (equity, deferred payment, etc.), and distinguishes from the sibling tool discount_request_response, making it easy for the agent to select correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly differentiates from discount_request_response and explains the three response modes (decline, counter, open_to_discuss) with clear guidance on when to use each. It could also mention when not to use the tool, but the distinction from the sibling provides adequate direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the action (writing an email), the behavior of the add_to_next_invoice parameter, and mentions it does not count against a monthly draft limit. It doesn't explicitly state whether the email is sent or drafted, but the context is sufficient for a non-destructive email tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently covers purpose, required/optional fields, and sibling distinctions. It is well-structured but could be slightly more organized with bullet points. Still very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, 3 required, no output schema), the description adequately covers the email's purpose, parameter roles, and usage context. It could mention the output (e.g., generated email text) but that is implicitly clear for an email generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds meaning beyond the schema by explaining the purpose of key parameters like add_to_next_invoice (framing as invoice heads-up) and payment_instructions (omit when add_to_next_invoice is true).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional reimbursement email and distinguishes it from sibling tools budget_update_email and invoice_cover_email by specifying different use cases (project expenses vs. budget overruns vs. labor billing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance for reimbursement requests, lists required and optional fields, and differentiates from two sibling tools. It lacks explicit 'when not to use' but the sibling distinctions imply alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses key behaviors: generates an email under 80 words, does not count against draft limit. Does not mention destructive actions, which is appropriate for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and immediately add valuable constraints. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool returns (the cover email) and its key elements (amount, due date, next step, under 80 words). Enough for an agent to understand the output without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter. The description adds no new parameter-level meaning beyond the schema, but it does contextualize that the email will include amount and due date (both parameters). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool writes a short professional cover email for an invoice, distinguishing it from sending a blank email. It specifies the content (amount, due date, next step) and constraints (under 80 words). Among many email siblings, this one is uniquely for invoice cover emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when sending an invoice and needing a professional cover email) and mentions a pragmatic note about not counting against monthly draft limit. However, it lacks explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the character limit, draft limit exemption, and style guidance (no pitch, genuine hook). It does not mention if the message is sent immediately or saved as a draft, but the core behavioral constraints are well documented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It front-loads the purpose, provides actionable guidelines, and ends with a reassuring note about draft limits. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema. The description does not mention what the tool returns (e.g., the crafted message text, a confirmation, or an error). For a tool that generates content, knowing the output format is important for the agent to handle the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all four parameters described. The description adds value by emphasizing specificity for 'reason_to_connect' and advising brevity for 'your_service' (5 words or fewer). This enhances the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a LinkedIn connection request message to a potential client or collaborator. It distinguishes from sibling 'linkedin_post' and other tools by focusing on private messages, not public posts or emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to be specific, low-pressure, and name a real reason to connect, avoiding pitches. It mentions the 300-character limit and that it doesn't count against draft limit. However, it does not explicitly state when to avoid using it or name alternatives for non-connection scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses a non-obvious behavioral trait: 'Does not count against your monthly draft limit.' It also specifies tone ('Warm, not transactional') and length ('under 150 words'). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is 5 sentences, efficiently conveying purpose, usage, tone, and special trait. It front-loads the core action. Slightly verbose with the ROI statement, but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the tool's output is a generated email, which is self-explanatory. Description covers purpose, target audience, tone, and constraints. It is complete for the agent to understand the tool's function and result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value for parameters like 'connection_hook' explaining its purpose ('Makes the email feel specific rather than templated') and 'recipient_service' giving examples. All required parameters are explained adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool writes a peer-to-peer outreach email for referral partnerships, with specific verb 'Write' and resource 'outreach email'. It distinguishes from sibling tools like referral_request by specifying the target (complementary service provider) and purpose (proposing a referral partnership).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description gives clear context on when to use: for outreach to complementary providers for referral partnerships, with examples of professional pairs. It does not explicitly state when not to use or mention alternatives, but the context is sufficient for an agent to select it among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool 'does not count against your monthly draft limit' and explains the three routes. However, it does not mention any side effects, authentication requirements, or error handling, which for a write tool might be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured: it opens with the main purpose, then explains when to use it, distinguishes routes, and finally lists parameters. Each sentence adds value, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of three routes and 8 parameters, the description covers the necessary context for using the tool. It explains the routes in detail and distinguishes from siblings. Missing is a description of the output format, but since it's an email generation tool, the output is self-explanatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing a baseline of 3. The description adds value by explaining the purpose of each optional parameter (e.g., plan_description, installment_count) and providing examples, as well as clarifying the routes and their respective use cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Write the email proposing or confirming payment installments for a project.' It uses a specific verb-resource combination and distinguishes itself from siblings like deposit_request_email, budget_negotiation_email, and payment_reminder_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'when a client can't pay the full fee upfront, or when you want to proactively offer a payment plan.' It also details three routes (propose_plan, respond_to_request, negotiate_back) and lists sibling tools that should be used instead in other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: offers preview and anonymize, gives easy out, and doesn't count toward draft limit. Lacks details on whether it sends the email or just drafts it, but otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with effective front-loading of purpose. Concise with no wasted words, though could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage context, differentiation from siblings, and an important side note (draft limit). Lacks explicit mention of output format or actions taken, but sufficient for an email generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions. The tool description adds context about how parameters are used (e.g., specific_work makes ask concrete) but doesn't significantly deepen parameter meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool writes an email asking for permission to feature a project, with specific content details. Distinctly separates from sibling tools testimonial_request and case_study_outline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (consent ask that must happen first) and when not (use testimonial_request or case_study_outline instead). Also notes it doesn't count against draft limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the transparency burden. It discloses that the tool generates a short email (under 120 words), does not count toward monthly draft limits, and has three specific goals. It does not mention output format or side effects, but for a content-generation tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the purpose and timing, then differentiates from siblings, explains goals, and lists parameters. It is somewhat lengthy but every sentence adds value. Could be slightly more concise, but structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the tool's output (a short check-in email with specific goals) and its usage context. It covers timing, content, and allowed parameters. Output format is not explicitly described, but the tool's nature as an email generator makes it implicit. Overall, sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions. The tool description adds context beyond the schema by explaining the purpose of the email, the timing window, and the rationale for optional fields (e.g., 'result_to_reference shows you've been paying attention'). This provides meaningful supplementary meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a short check-in email sent 30-60 days post-launch, explicitly distinguishes it from sibling tools (project_go_live_email, project_completion_email, upsell_email), and lists three specific goals. The verb 'Write' plus specific resource and timing make purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the exact use case (30-60 day post-launch window) and differentiates from three sibling tools by naming them and contrasting their timing/purpose. It provides implicit guidance on when to use (4-8 week window) but stops short of explicitly stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes the tool as proactive, professional, and not counting against monthly draft limit. Indicates it is a write operation but without destructive consequences. Lacks detail on whether email is sent immediately or drafted, but sufficient for understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with three sentences, front-loading the purpose. Every sentence adds value (purpose, when to use, sibling distinction, monthly limit). Could be slightly more streamlined, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 7 parameters (4 required), the description provides sufficient context: purpose, timing, differentiation from sibling, and an operational detail (draft limit). Lacks info about return value or side effects, but adequate for agent decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema; it provides context for the tool's purpose but does not elaborate on individual parameters. Adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a proactive warning email before a deadline is missed, using specific verbs 'Write a proactive email warning'. It distinguishes from sibling 'late_delivery_apology' by specifying timing (before vs after missing deadline).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (BEFORE actually missed deadline) and when not to ('Different from late_delivery_apology'). Provides context: 'professional middle path between staying silent and over-apologising', giving clear guidance on appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses two routes with different tones, states it doesn't count against draft limit, and lists required/optional parameters. It does not specify if the email is auto-sent or just drafted, but the intent is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: starts with purpose, then usage context, then route options, then parameters. It is somewhat lengthy but front-loaded and each sentence adds information. Minor redundancy in route explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description covers all necessary aspects: required and optional params, route options, draft limit benefit. It is sufficient for an email drafting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description adds value by explaining the difference between warm and clean routes, providing examples for handover_reason and next_steps, and clarifying optional fields beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes an email for handing over a project to another developer/contractor. It distinguishes two routes (warm and clean) and explains when each applies, differentiating it from sibling email tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (e.g., stepping back, client moving in-house, bringing in specialist) and describes the two routes. However, it does not explicitly mention when not to use it or direct alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fails to disclose behavioral traits such as whether the email is actually sent or just generated, or any authentication requirements. It does mention the tool does not count against a monthly draft limit, which adds some transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 sentences) and front-loaded with the primary purpose. Every sentence adds value without redundancy, achieving high density of useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, 3 required, no output schema), the description is complete. It covers the tool's role, lifecycle relationship, email structure, and a notable constraint (draft limit). No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description does not add significant meaning beyond the schema; it explains the email structure but does not augment parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional email to restart a paused project, with a specific verb and resource. It also distinguishes itself from the sibling project_pause_email, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly pairs this tool with project_pause_email, indicating it is used after a pause. This provides clear when-to-use and when-not-to-use guidance, and references an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility. It discloses that the tool does not count against monthly draft limits, adding useful behavioral info. However, it does not mention other traits like no side effects on the original proposal or auth requirements, which would elevate the score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences plus a critical behavioral note, with the main action stated first. Every sentence adds necessary information without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains what the tool produces (short email with 4 key points), covers all parameters, and adds the draft limit info. For a simple generation tool with only one required param, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters are fully described in the input schema (100% coverage). The description adds value by explaining the optional cta parameter behavior (inference if omitted) and the roles of client_name and your_name in greeting/sign-off, going beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('convert', 'distills') and identifies the resource (proposal document) and output (pitch email). It explicitly states the key points included (problem, solution, price, next step) and differentiates from siblings by focusing on existing proposal conversion rather than cold outreach or other email types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you have a proposal and want a short client email) but does not explicitly state when not to use or list alternatives. The context is clear enough for an agent to infer appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the key technique (offering to write a draft), length constraint ('Under 80 words'), tone ('no guilt, no pressure'), and the impact of the 'offer_draft' parameter. It does not describe return format or potential side effects, but for a text generation tool, the behavioral aspects are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and includes several informative sentences. Each sentence adds value: timing, distinction, key technique, length constraint, optional param importance, and draft limit note. It could be slightly more concise, but it remains efficient and clear with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description covers nearly all relevant aspects: purpose, timing, sibling differentiation, behavioral details, and parameter effects. It does not explicitly state the return format, but it is implied that the tool outputs an email text. The description is sufficiently complete to guide correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, granting a baseline of 3. The description adds value by explaining the purpose of 'project_name' (makes email feel specific) and emphasizing 'offer_draft' as the highest-impact line. This additional context improves parameter understanding beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Write a gentle follow-up when a testimonial request has gone unanswered', specifying the verb (write) and resource (follow-up email). It distinguishes from the sibling 'testimonial_request' by calling it the nudge that increases conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides timing ('one to two weeks after the initial testimonial_request') and distinguishes from the sibling 'testimonial_request'. It also notes that the tool does not count against the monthly draft limit. However, it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full transparency burden. It notes the tool does not count against monthly draft limit and that it generates an approval request. However, it does not clarify whether the email is drafted or sent, leaving minor ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise: 5 sentences covering purpose, benefit, sibling distinction, behavioral trait, and parameter listing. No wasted words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides sufficient context for a simple email generation tool: purpose, usage, key parameters, and an important behavioral note. Lacks explicit mention of output format (draft vs. sent), but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. Description adds value by listing required/optional groups but does not significantly augment schema descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool writes a change order email to confirm additional work with scope, cost, and timeline impact, and asks for written approval. It explicitly distinguishes from sibling tool scope_creep_email, providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: for agreed extra work, and identifies alternative tool (scope_creep_email) for unwanted additions. Provides clear guidance on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool does not count against monthly draft limit and implies it creates an email draft. Additional behavioral details like permissions or side effects are not needed for a write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded: purpose, usage context, sibling differentiation, and a behavioral note in three sentences. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description clearly implies the tool returns an email draft. It covers purpose, scope, and differentiation from siblings. Slight gap: does not explicitly state the output format, but it's well-understood as an email generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about the overall structure but does not enhance individual parameter definitions beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool writes a structured end-of-engagement email with a handover checklist. It distinguishes from two sibling tools (client_offboarding_email and project_closure_email) by specifying this is an operational handover with action items and checklist format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Sent at project close or retainer end' and distinguishes from sibling tools, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the email opens the renewal conversation, references work done, and does not count against the draft limit. It explains the two routes and optional parameter behavior, offering good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs, front-loaded with purpose. It includes some narrative detail ('Most freelancers...') which adds context but could be trimmed. Overall, every sentence contributes value, and it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, 2 required, and no output schema, the description is thorough. It covers all parameter roles, default behavior, optionality, and route implications. The agent has sufficient information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds valuable context beyond schema, such as explaining optional fields like end_date ('makes the ask feel timely'), work_summary ('reminds the client of value'), and new_rate behavior when omitted ('proposes discussing updated terms'). This enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional contract or retainer renewal email. It specifies the verb 'write' and the resource 'renewal email,' and distinguishes itself from siblings by focusing on renewals. The two routes (same_terms/revised) provide specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool ('before an engagement ends') and provides context about common freelancer mistakes. It describes the two routes but does not explicitly exclude alternatives or state when not to use it. However, given the large sibling set, the differentiation is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds good behavioral context: it explains the email's content structure and optional parameters' effects (e.g., signing_deadline changes sign-off). It does not detail any side effects, but the tool is a content generator with no destructive actions implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, no fluff. Every sentence adds essential information about the tool's function and distinctiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a content generation tool with no output schema or annotations, the description provides a solid understanding of what the email contains and the optional inputs' behavior. It could be improved by explicitly stating the output (e.g., 'returns the email text').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining how optional parameters affect the email content (e.g., signing_deadline omission changes sign-off, signing_link presence changes CTA), which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's action ('Write the short covering email') and resource ('contract or agreement'), and distinguishes it from the sibling tool 'contract_template' by clarifying that this is the email wrapping the contract, not the document itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains what the email does and differentiates it from 'contract_template', providing clear context. However, it does not explicitly mention when not to use it or provide alternatives among other sibling tools like follow-up emails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool generates a reader-first pitch with specific structure (angle, credibility, frictionless ask) and notes it does not count against the monthly draft limit. No contradictions or hidden behaviors are evident, though details like character limits or formatting are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, using multiple sentences to convey purpose, context, structure, and sibling distinctions. Every sentence adds value, but it could be slightly shorter without losing clarity. It is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no output schema, the description is fairly complete: it explains the input purpose, output structure (pitch email), and extra benefits (draft limit). Missing details like output format (plain text vs. HTML) might affect completeness slightly, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have schema descriptions, and the tool description adds significant meaning beyond them—e.g., for 'article_angle', it emphasizes framing as value for readers, not self-showcase. This extra guidance helps the agent use parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool writes a cold pitch email for guest articles, with a specific verb ('Write a cold pitch email') and resource ('blog, newsletter, or publication'). It explicitly distinguishes from three sibling tools (podcast_pitch_email, conference_talk_pitch, cold_pitch), making purpose and boundaries very clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for SEO, backlinks, audience building) and provides guidance on what makes a good pitch (reader-first, not ego-driven). It names alternative tools for different contexts. However, it does not explicitly state when NOT to use this tool beyond the sibling distinction, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behavioral traits: the email is reply-all, high-stakes, under 120 words, and does not count against monthly draft limit. It also sets expectations for tone and structure. The description is transparent about the tool's purpose and constraints, though it does not cover error conditions or exact output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 4 sentences) and front-loaded with the primary purpose. Every sentence adds value: use case, importance, constraints, and a unique benefit (does not count against monthly limit). No wasted words, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (generating an email), no output schema, and no annotations, the description provides sufficient context: it explains the email's purpose, audience, constraints, and workflow position. It doesn't specify the return format, but for a generative tool, the output (email) is implied. The sibling list shows many email tools, and this description clearly positions this one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes each parameter. The description adds valuable context: for example, 'their_context' is explained as making the email feel specific, and 'proposed_next_step' defaults to a call. This extra guidance helps the agent use parameters effectively beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a reply-all email when a mutual contact introduces you to a potential client, with a specific verb (write) and resource (email). It distinguishes itself from sibling tools like cold_pitch or referral_request by specifying the exact scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'when a mutual contact introduces you to a potential client over email'. It explains the email's goals and constraints (under 120 words, acknowledge introducer, impress prospect). While it doesn't explicitly list when not to use it, the specific framing and mention of 'workflow gap' effectively guide appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses tone (firm, factual, no threats), calibration by route, and the note about draft limits. It also lists required and optional parameters, providing comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but well-structured with front-loaded purpose and usage. Every sentence earns its place, though it could be broken into smaller paragraphs for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters and usage context well, but lacks any mention of what the tool returns (e.g., email body or confirmation). Given the complexity of 9 parameters, this is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds some value by explaining the escalation_route parameter further (defaults to 'legal') and providing usage context for senior_contact_name, but it largely restates schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes a professional email for escalating unpaid invoices. It specifies the resource (unpaid invoice) and the verb (escalating), and distinguishes from the sibling 'payment_reminder_email' by noting it is used after that reminder has gone unanswered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: after a final payment reminder has gone unanswered. It also details three routes (manager, legal, agency) and their specific use cases, and notes that it does not count against the monthly draft limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the tool summarizes discussions, confirms decisions, lists next steps, and creates a paper trail. It also notes the draft limit policy. It does not mention if it sends the email or only drafts, which is a minor gap, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each providing distinct information: purpose, actions, benefit, and draft limit. Front-loaded with purpose, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 7 parameters (all documented), the description adequately covers what the tool does and what inputs are needed. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context: meeting_type shapes tone, key_points are rough notes shaped into prose, and next_steps include owners. This adds value beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a post-meeting recap email, specifies the resource (email to client after meetings), and lists meeting types (discovery, check-in, kickoff, review). It distinguishes from other email tools by focusing on post-meeting recaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (after specific meeting types) and mentions it does not count against draft limit. It does not directly exclude alternatives but given the context, the usage is clear. Could be improved by noting when not to use, but it is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds useful behavioral context (does not count against draft limit) but does not disclose other traits like idempotency, side effects, or permissions. For a writing tool, this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 sentences) and front-loaded with the core purpose. Every sentence adds unique value, avoiding redundancy or filler. It efficiently conveys purpose, usage, and key behavioral notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 100% schema coverage, and no output schema, the description provides sufficient contextual examples and usage scenarios. It lacks return value description, but that is standard for email drafting tools. Overall, it is complete enough for correct tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds value by providing illustrative examples for parameters like meeting_purpose, time_options, and context. This helps the agent understand expected input formats beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a meeting request email and specifies use cases (discovery call, check-in, catch-up). It distinguishes itself from siblings by referencing cold pitch and discovery_call_prep, and notes it does not count against draft limit, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use the tool (discovery call, check-in, catch-up) and implicitly when not to (e.g., cold pitch, other email types). It also mentions the workflow gap it fills, providing clear guidelines relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses tone (solution-focused, not punitive), content (states plan clearly, confirms in writing), and a key behavioral trait: 'Does not count against your monthly draft limit.' No mention of auth or side effects, but email drafting implies read-like safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus sibling list) and front-loaded with purpose and usage. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and no output schema, the description adequately explains the email's content and tone, plus a useful behavior note about draft limits. While it doesn't detail the return value, the purpose is clear enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a description. The tool description does not add significant meaning beyond the schema. It implies that parameters like number_of_payments, first_payment, schedule_description are used to construct the plan, but that is inferrable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes a professional email proposing an installment payment plan when a client cannot pay in full. It specifies the action, resource, and distinguishes from sibling tools immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit conditions for use: proactively offered when sensing payment difficulty or as a reply when client asks for more time. Also clearly distinguishes from three sibling tools (late_payment_reminder, invoice_dispute_response_email, deposit_request_email).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It discloses key behaviors: tone calibration, politeness, avoidance of passive-aggression, no impact on draft limits. It also states required vs optional parameters and the auto-selection logic for tone. It does not mention any potential side effects or restrictions beyond the parameters, but overall provides adequate transparency for a safe email generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about five sentences, front-loading the core purpose and then logically detailing tone calibration and parameter usage. Every sentence adds value, and there is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8 parameters, 2 required, and no output schema, the description covers the main behavior thoroughly: it explains tone selection, parameter roles, and the fact that the tool does not consume draft limits. It lacks explanation of the return value (the generated email text), but since there is no output schema, this is acceptable. The description is sufficiently complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the tone auto-selection algorithm based on days_overdue, the override behavior of tone parameter, and the fact that the tool doesn't affect draft limits. This synthesis goes beyond the individual parameter descriptions, justifying a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Write a professional payment reminder email for an overdue or upcoming invoice.' It specifies the verb 'write' and the resource 'payment reminder email', and distinguishes from siblings by detailing tone calibration and auto-selection logic, which is unique among related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each tone based on days overdue (friendly for 1-7 days, firm for 8-21, final for 22+). It also notes that the tool does not count against a monthly draft limit. However, it does not explicitly differentiate from overlapping sibling tools like 'late_payment_reminder' or 'payment_overdue_final_notice_email', missing opportunities to state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states 'Does not count against your monthly draft limit', which is a behavioral trait. It also clarifies the output is an email with agenda and format confirmation. It does not explicitly state whether it sends immediately or saves as draft, but the wording suggests it writes a draft.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is approximately 120 words, front-loaded with the core purpose, then briefly lists parameters, and adds lifecycle and limit info. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description covers the lifecycle, draft limit, and parameter usage well. It does not explain the return value, but it is reasonable to assume it produces an email draft. Minor gap but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value beyond the schema by providing usage context (e.g., 'Auto-formatted as a numbered list' for agenda_items, examples for prep_request, 'for the sign-off' for your_name).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Write a short email sent 24 hours before a scheduled meeting to share the agenda and confirm the format.' It specifies the timing and content, and distinguishes from siblings by placing it in the meeting lifecycle: meeting_request_email → pre_meeting_email → meeting_recap_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('24 hours before a scheduled meeting') and outlines the meeting lifecycle, implying alternatives. It does not explicitly mention when not to use it, but the lifecycle provides clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the tone (non-pressuring, specific), the two behavioral modes, and that the tool does not count against a draft limit. It does not mention any destructive actions or side effects, which is appropriate for a 'write email' tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence. It then efficiently covers modes, timing, tone, required and optional parameters, and a practical note about draft limits. Every sentence serves a clear purpose without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, modes, parameters, and usage tips. Given the rich schema descriptions and absence of an output schema, it provides sufficient context for correct tool invocation. It could mention the output format (text/email draft), but the schema indicates it's a generated email, so this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that testimonial_platform is only used in feedback_and_testimonial mode, providing the statistic about response rates, and explaining the purpose of specific_question. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Write a professional email asking a client for feedback after completing a project.' The verb 'write' and resource 'email' are specific, and the two modes are explained, distinguishing it from siblings like 'feedback_request_email' and 'testimonial_request'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description describes two modes for different scenarios (feedback only vs. feedback + testimonial) and mentions timing ('within a week of delivery gets 3x the response rate'). However, it does not explicitly state when not to use this tool or provide direct comparisons to siblings like 'feedback_request_email'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It reveals that the tool writes an email, does not count against a draft limit, and that sections are conditional based on parameters. It does not explicitly confirm email sending, but the context implies it. Overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the core purpose and then listing required/optional parameters. However, it is somewhat verbose, repeating details already in the schema. Slight condensation would improve conciseness without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 9 parameters, the description covers the tool's functionality comprehensively. It explains optional sections and their omission behavior. Missing is explicit mention of the return value (e.g., generated email text) and any side effects, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds significant value by explaining the role of each parameter in the email structure (e.g., 'if omitted, this section is skipped'), providing usage examples, and clarifying defaults (timeline_status). This goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's purpose: writing a clear, scannable project status update email for regular cadence. It details content coverage (completed, in progress, coming next) and optional sections, distinguishing it from sibling email tools like project_kickoff_email or project_closure_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use (weekly, bi-weekly, at a milestone) and mentions it keeps clients informed without a call. However, it does not explicitly exclude alternative use cases or compare with similar tools, leaving minor ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the email's tone ('no apologising, no burying the number') and that it does not affect draft limits. However, it does not explicitly state side effects (e.g., whether the email is saved or sent) or authorization needs, but the generative nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but well-organized: purpose first, then usage distinctions, then parameter list. It is front-loaded and efficient, though could be slightly more structured for quick scanning. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify return value (e.g., generated email text). The description omits what the tool outputs, which is a gap. However, the input and purpose are thoroughly covered, and the sibling context is clear. The missing output detail prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds value by explaining the role of each optional parameter (e.g., rate_context as 'one sentence on what is included'), providing examples, and giving usage guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional email for prospects asking about rates, with specific verb ('write') and resource ('email'). It explicitly distinguishes itself from sibling tools `draft_proposal` and `rate_increase_email`, ensuring the agent selects the correct tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use: 'when a prospect asks what are your rates?' and when-not-to-use by contrasting with `draft_proposal` and `rate_increase_email`. It also notes it 'does not count against your monthly draft limit,' adding usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It adds useful behavioral context: 'Does not count against your monthly draft limit.' It also implies an email generation action but does not mention required permissions 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. First sentence states purpose, second provides context, third distinguishes from siblings and adds draft limit info. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 14 parameters (many optional) and no output schema. Description covers when to use, what it produces, and distinguishes from alternatives. It adequately fills gaps given the rich input schema. Could mention the output is a full email body, but inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond what the schema already provides for parameters. The schema itself describes each parameter sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Write a professional email'), resource ('productized service packages'), and scope ('2–3 packages, fixed-price structured tiers'). It distinguishes from siblings 'rate_card_email' and 'draft_proposal'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when you offer fixed-price, structured tiers') and when not ('rather than quoting per project'). Names alternatives ('Distinct from rate_card_email... and draft_proposal').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: 'Does not count against your monthly draft limit.' It also implies the action is non-destructive and generates an email, which is sufficiently transparent for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but slightly lengthy. It front-loads the purpose, includes sibling differentiation and the limit disclosure. A minor reduction in redundant phrasing could improve conciseness, but it is well-structured overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple email generation tool with 8 well-documented parameters (2 required) and no output schema needed, the description covers the tool's purpose, usage context, distinguishing features, and behavioral impact (draft limit). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description does not add new parameter details beyond the schema, but it helps by explaining the email's purpose, which implicitly guides parameter selection. No additional value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Write a short, friendly email' and clearly distinguishes the tool from siblings (contract_template, client_onboarding_checklist, project_kickoff_email) by explaining what each sibling does and how this one differs. The verb (Write) and resource (email) are specific, and the scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Sent before or at project kick-off' and provides explicit when-to-use context. It also lists alternative tools for different purposes (e.g., contract_template for legal obligations), offering clear guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 the email's tone, framing, and a key behavioral trait: 'Does not count against your monthly draft limit.' This adds beyond the schema. However, it does not detail whether the tool sends or only drafts, or any authentication/rate limit implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the core action, then tone, then use cases, then a benefit. Every sentence adds value, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (2 required, 1 enum), no annotations, and no output schema, the description is quite complete. It covers parameter roles, scenarios, and a behavioral note. It does not describe the output format, but without an output schema, that is acceptable. It could optionally mention that it generates a draft email.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds value by explaining the tone and scenarios, and by describing the trigger enum and its three values. This context helps the agent choose appropriate values beyond the schema's bare definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Write a brief, professional email setting expectations about your working hours and response times with a client.' It specifies the tone ('confident and matter-of-fact') and the framing ('boundaries as something that helps'), and lists concrete use cases (proactive, after late message, mid-project reset), effectively distinguishing it from sibling email templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage contexts: 'Works for setting hours proactively at project start, responding after a late-night or weekend message, or resetting expectations mid-project.' It does not explicitly mention when not to use or alternatives, but the scenarios are clear and the trigger parameter further guides selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses that the tool generates a non-upsell, human-toned email under 100 words with optional personalization fields. States it does not count against monthly limit. No mention of side effects or authentication, but for a generation tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is roughly 150 words, well-structured with front-loaded purpose and differentiation. Every sentence adds information without redundancy. Minor length could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains the nature of the output (email under 100 words, warm, no pitch). It covers usage, parameter nuance, and differentiation. Could include edge cases like milestone format flexibility, but not essential for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds value by explaining how optional parameters (project_or_relationship, standout_moment, forward_line) contribute to specificity and warmth, going beyond basic schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a short, warm anniversary email for long-term clients, distinguishes from sibling annual_review_email, and specifies constraints (no pitch, no ask, under 100 words). The verb 'Write' plus resource 'email marking anniversary' makes it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with annual_review_email, stating this is relationship-first with no deliverables or pitch. Provides when-to-use (anniversary acknowledgment) and when-not-to (structured retrospectives). Also mentions it doesn't count against monthly draft limit, adding practical context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the high-stakes sales moment, relationship risk, and three response routes. However, it does not explicitly state whether the tool sends the email or just drafts it, though the phrase 'does not count against your monthly draft limit' implies a draft is generated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but not wasteful; each sentence adds value. It front-loads the purpose and then provides detailed guidance. Could be slightly more concise, but the complexity of the tool (three routes) justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify what the tool returns (e.g., an email draft). It hints at 'does not count against your monthly draft limit' but does not explicitly state the output format or how to use the result. For a tool with multiple routes and high-stakes context, this is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for each parameter, but the tool description adds rich context with concrete examples for condition_requested and counter_offer, and explains the route enum options with usage scenarios. This goes beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating responses when a client says 'yes, but...' and asks for changes. It distinguishes from three sibling tools (discount_request_response, budget_negotiation_email, price_objection_response_email) by explaining the specific scenario where this tool applies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use (client accepted but requests changes) and when not to (alternatives listed with clear differentiators). Also provides guidance on the three routes (accept, counter, hold) with conditions for each.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses a key behavioral trait: 'Does not count against your monthly draft limit', which is valuable for resource management. It also clarifies the tone ('without being heavy or legalistic'). However, it does not explicitly state whether the tool returns the email text or sends it, nor does it discuss authentication or rate limits, but the context (cover email) implies text generation, which is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action: 'Write the short covering email...'. The description is moderately concise, with each sentence providing distinct value. It could be slightly tighter (e.g., combining some optional parameter notes), but overall well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description acknowledges the output implicitly (the email). It covers purpose, audience, content, and key parameters. With 5 parameters (1 required) and no nested objects, the description is sufficiently complete for an agent to select and use the tool correctly, though it could explicitly state the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds meaning by explaining each optional parameter in context: e.g., `project_description` is 'brief note on the project the NDA covers', `relationship` defaults to 'client', `signing_method` gives examples. This adds practical guidance beyond the schema descriptions, enhancing usability for an AI agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes a covering email to accompany an NDA, using specific verbs ('write') and resource ('covering email'). It distinguishes from sibling tools `nda_template` (generates the NDA) and `subcontractor_brief` (briefs a subcontractor), giving a unique identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: sending NDA to client or subcontractor. Provides when-not-to-use by naming alternatives (`nda_template` for the NDA itself, `subcontractor_brief` for briefing). Also explains what the email covers (why sending, what it covers, what to do) without being legalistic, guiding the agent on appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's behavior: it generates a short professional email with specific tone constraints. It reveals that the tone is calibrated by days_since_sent parameter, that it avoids guilt, and that it includes an easy out. Also discloses that it does not consume monthly draft limit. No contradictions or omissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but efficient, front-loading the core purpose and then differentiating with siblings. It uses clear, direct language. A few extra phrases ('the hardest follow-up to write because it feels pushy') add empathy but don't waste space. Could be slightly shorter, but well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and many sibling tools, the description provides enough context to use correctly: it explains when to use, tone, length constraint, and parameter usage. It does not describe the return format, but that's acceptable as output is presumably the generated email text. A minor gap: no mention of how the email is returned (draft, copy, etc.), but still complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter already well-described (e.g., client_name, days_since_sent for tone calibration). The tool description adds no additional parameter-level meaning beyond what the schema provides. Baseline of 3 is appropriate per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional follow-up email when a client has agreed but not signed. It explicitly distinguishes itself from three sibling tools by naming their specific contexts (never replied, proposal not approved, closing out ghost). The verb 'write' and resource 'follow-up for unsigned contract' are precise and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: 'after the handshake: they said yes, you sent the contract, now it's sitting unsigned.' Also tells when-not-to-use by contrasting with sibling tools. Includes tone guidance (matter-of-fact, no guilt, under 100 words, gives easy out) and a system behavior note (doesn't count against draft limit). Comprehensive and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It adds the note about not counting against monthly draft limit, plus explains the three modes' behaviors. Could mention return format, but that's minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: purpose, stakes, how it works, benefit, and side-effect. Front-loaded and zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (6 params, 3 modes) and no output schema, description covers usage, parameter guidance, and behavioral note. It's complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. Description adds value by contextualizing the response_mode enum and explaining when to use each mode, which complements schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool writes a response to discount requests, with three specific modes. It distinguishes from siblings by focusing on this precise use case, unlike general decline or negotiation emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'when a client asks for a lower price', giving clear context. Lacks explicit alternatives or when-not-to-use, but the context is strong and sibling list suggests suitable cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's behavior: it generates a professional, calm, non-defensive reply. It describes the three response modes (explain, adjust, clarify) and their intended uses. It also mentions that the email does not count against a monthly draft limit. However, it does not detail potential limitations or side effects, but overall it provides solid behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it starts with the core purpose, then lists the modes, contrasts with siblings, and adds tone and a bonus note. It is front-loaded with the most important information. While it is a bit lengthy, every sentence adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters (2 required, 1 enum) and no output schema, the description adequately covers the scenario, modes, and differentiation from siblings. It provides enough context for an AI agent to understand the tool's purpose and when to use it. The absence of output schema is acceptable as the tool generates an email, whose format is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds significant value by explaining the three modes and providing examples of what to use in explanation and adjustment parameters. It clarifies the context of each parameter beyond the schema's descriptions, making the tool more intuitive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing a professional reply when a client disputes an invoice charge. It specifies the three response modes (explain, adjust, clarify) and distinguishes this tool from related siblings like late_payment_reminder, budget_update_email, and scope_change_email. The verb 'Write' and resource 'professional reply' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly defines when to use this tool: when a client disputes or questions a charge. It provides contrasting contexts for sibling tools (e.g., late_payment_reminder for non-disputed non-payment, budget_update_email for pre-invoice cost increases, scope_change_email for formal change orders). It also clarifies that this is for the specific situation where the client has received the invoice and is pushing back on a line item.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the email's purpose and tone, plus the benefit of protecting timeline and avoiding confrontation. Also notes it does not count against draft limit. No annotations provided, so description carries the full burden; it is mostly transparent but could mention if email is sent immediately or saved as draft.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, content points, sibling distinction, routes, and parameter list. Front-loaded with core action. Could be slightly shorter but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a tool with 7 parameters (4 required) and no output schema. Explains the email's components, route variations, and parameter meanings. Lacks discussion of return value, but for an email-sending action this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds context beyond schema by explaining the required parameters in narrative form and providing examples. It also elaborates on the route enum meanings, adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes an email confirming receipt of late materials, noting the timeline impact. It lists four specific actions (a-d) and distinguishes from two sibling tools, ensuring no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance (client materials late), what to include (four points), and three route options (brief, significant_impact, repeated). Distinguishes from client_material_chase_email and project_delay_notification_email with clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that the tool writes an email (non-destructive), does not count against monthly draft limit, and describes the three routes. However, it does not explicitly state whether the tool sends the email or returns the draft text, leaving some ambiguity about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with purpose, then detailing routes, sibling differentiation, and parameter list. While slightly long, each sentence adds value. Minor improvement could be tighter wording, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers input parameters, routes, and sibling differentiation. It explains when to use each route and provides examples. However, it lacks a clear statement about the output (email draft text), which would improve completeness for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value beyond the schema by explaining route defaults, providing examples for amount and invoice_number, and clarifying next_step usage. The extra context for fields like days_overdue and route enhances understanding beyond schema descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes an unpaid invoice email, specifies three routes (gentle, firm, final_notice), and explicitly distinguishes from siblings re_engagement_email and contract_renewal_email. The verb 'Write' combined with the resource and context makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each route based on days_overdue (1-7 gentle, 8-21 firm, 22+ final_notice) and mentions default selection. It also names specific sibling alternatives (re_engagement_email, contract_renewal_email) to avoid confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description notes a behavioral trait: 'Does not count against your monthly draft limit.' It does not contradict any annotations. It could explicitly state whether the email is drafted or sent, but the given context is sufficient for a drafting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states purpose, second lists params, third mentions siblings and a constraint. No wasted words; front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no output schema, the description covers purpose, parameter details (required/optional), sibling relationships, and a special behavior (draft limit). It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds value by rephrasing parameters in plain language and adding usage nuances (e.g., 'brief, honest one-line — omit if no clean reason' for reason), improving understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Write a professional email to cancel or reschedule a meeting,' specifying the verb ('write') and resource ('email'). It distinguishes from siblings by naming 'meeting_request_email' and 'meeting_recap_email.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description links to related tools ('Pairs with meeting_request_email and meeting_recap_email') and specifies required parameters. It implies when to use via action enum (cancel/reschedule) but lacks explicit when-not-to-use or alternative selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool does not count against monthly draft limits, describes three routes with appropriate tones, and lists required/optional parameters. However, it does not specify whether the tool sends the email or only drafts it, nor does it mention any side effects beyond draft creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, then routes, sibling differentiation, and parameters. However, it is somewhat verbose; bullet points for routes and parameters could improve scannability without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input thoroughly but omits information about the output. Since there is no output schema, the description should explain what the generated email looks like (e.g., subject line, body structure). Additionally, it does not mention any required prerequisites or permissions needed to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds significant value by explaining each parameter's role, providing examples, and detailing the route enum values with usage context. This exceeds what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing an email to request client approval for a milestone, concept, or phase. It distinguishes three specific routes (milestone_complete, design_concepts, staged_delivery) and contrasts with sibling tools like deliverables_sign_off_email, brief_confirmation_email, and project_status_update_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('for when you need a clear go-ahead... to protect against scope disputes') and provides detailed scenarios for each route. It also clarifies what the tool is not for by listing distinct sibling tools and their purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool does not count against monthly draft limits and sets expectations for tone (firm, factual, unambiguous). However, it does not clarify whether the tool actually sends the email or only drafts it, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is logically structured and front-loaded with purpose and usage. It provides necessary information without redundancy, though it could be slightly more concise by trimming some explanatory phrases. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and moderate complexity, the description covers purpose, usage, parameter details, and sibling differentiation. It lacks explicit mention of return values (e.g., draft text content), but as an email drafting tool, this is partially inferable. Overall, it is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by listing required and optional parameters, specifying defaults (e.g., payment_deadline defaults to 7, next_step defaults to work_suspension), and explaining enum options for next_step. This surpasses basic schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes a formal final notice email for overdue invoices, using a specific verb and resource. It explicitly distinguishes from sibling tools 'late_payment_reminder' and 'invoice_dispute_response_email', providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use (client not responded to previous reminders, significantly overdue) and contrasts with alternatives, including explicit 'when-not-to-use' through sibling differentiation. It also notes this is the last communication before escalation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description conveys it generates a short celebratory email. It doesn't explicitly state side effects or output format, but the generative nature is clear and common for such tools. Slightly lacking explicit non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is thorough but not overly verbose; front-loaded with core purpose. Each sentence adds value, though could be slightly more concise. Well-structured with parameter explanations integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers usage, parameters, and differentiation well. It omits explicit output description but implies generated email text. Contextual completeness is high for a content generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds meaningful context for optional parameters like 'early_result' and 'next_hook', including examples and usage guidance. Provides value beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a celebratory email for a project go-live, distinguishing it from sibling tools (project_completion_email, project_closure_email). It uses specific verbs and resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (project go-live), distinguishes from alternatives, and provides constraints (under 100 words, warm tone, no pitching). Includes natural moment for next work without hard sell.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It discloses that the tool 'does not count against your monthly draft limit' and describes the three routes with clear outcomes. However, it does not explicitly state whether calling the tool multiple times overwrites previous emails or creates new ones, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then routes, sibling differentiation, draft limit note, then parameter list. It is somewhat lengthy but every sentence adds necessary context, so no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for an email generation tool: when to use, what it produces (a proposal email), key distinctions, and parameter guidance. Without an output schema, it does not need to describe return values, but the description is complete enough for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by listing required vs optional params with examples and explaining the route enum in detail, aiding correct parameter selection beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool's verb ('Write the email'), resource ('maintenance retainer or support agreement'), and context ('after delivering a project'), making its purpose very clear. It also explicitly distinguishes itself from sibling tools retainer_proposal and service_package_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool ('after delivering a project') and provides direct alternatives (retainer_proposal, service_package_email), along with a brief explanation of when each sibling is appropriate. This gives the agent a clear decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses tool creates an email, does not count against monthly draft limit, and has three behavioral routes. Lacks explicit statement on side effects (e.g., whether email is saved or sent) but otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is long but well-structured: starts with purpose, then sibling differentiation, route explanations, parameter details, and end note. Every sentence adds value, but some phrases (e.g., 'Its job: create urgency...') are slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema provided, but description does not explain what the tool returns (e.g., generated email text or draft). Missing output specification for a tool with multiple routes. Other aspects (parameters, routes) are well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning description adds value beyond schema. For route, it explains usage per enum value; for proposal_value, it states re-anchors investment; for expiry_date, clarifies behavior if omitted. Enriches parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states tool writes follow-up emails for proposals approaching or past expiry. It names three routes and clearly distinguishes from three sibling tools (client_followup, bid_lost_follow_up, post_discovery_follow_up_email) with specific differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance for each route: gentle_nudge as default, firm_deadline when deadline is tomorrow/past, extend_offer when willing to wait. Also notes tool is for submitted proposals. Distinguishes from siblings with clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains that the email summarises, previews, and opens door for upsell, and keeps relationships active without feeling like a report. It does not contradict any annotations (none provided). Missing details like auto-send but sufficient for an email draft tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient paragraphs: first outlines purpose and effects, second lists parameters with concise explanations plus workflow and draft limit note. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (email generation), the description is comprehensive: purpose, required/optional fields, defaults, workflow positioning, and draft limit. No output schema needed, so missing return value explanation is not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so description adds value beyond schema by clarifying required vs optional, providing defaults (e.g., new_needs_question defaults to general open-ended check), and giving usage guidance for each parameter (e.g., 'omit to keep it brief and open').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool writes a monthly check-in email to retainer clients, summarizing work, previewing upcoming work, and opening the door for upsells. It clearly distinguishes from sibling tools like 'client_check_in_email' by specifying 'retainer' and the monthly cadence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists required and optional parameters and provides a workflow sequence ('retainer_proposal → project_kickoff_email → retainer_check_in_email (monthly) → contract_renewal_email'), giving clear context on when to use it. It does not explicitly state when not to use or list alternatives, but the workflow implies its place.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description covers the three routes, clarifies required vs optional parameters, and mentions that it does not count against a monthly draft limit, adding valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loading the purpose and routes, then distinguishing siblings, then listing parameters. While slightly long, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers all necessary context: purpose, routes, parameter details, sibling differentiation, and even mentions the draft limit. Lacks explicit output description but otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description enhances parameters with examples and context (e.g., example values for current_retainer and proposed_expansion, route enum explanation).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes an email to expand an existing retainer, specifies three distinct routes, and differentiates from sibling tools with explicit examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use ('ongoing retained relationship...based on work done so far') and distinguishes from sibling tools like retainer_proposal, retainer_check_in_email, and new_service_announcement_email.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the email's purpose, tone, and that it does not count against draft limit. However, it doesn't specify if the email is actually sent or just drafted, but given tool context (email generation), this is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One paragraph, front-loaded with purpose, then details, sibling differentiation, and draft limit note. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With high schema coverage and no output schema, description fully explains the email's content, tone, and when to use. Includes note about draft limit, making it complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all 7 parameters. The description adds overall context but doesn't provide additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it writes a professional email about rush fee, names the specific action (write) and resource (email to client). Distinguishes from siblings like budget_update_email, scope_change_email, and project_extension_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: notifying client about rush fee and asking for approval. Lists exact sibling alternatives and their use cases, guiding selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool does not count against monthly draft limit and explains behavioral outcomes of two routes. Could mention sending behavior or further side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is detailed but efficient, front-loading purpose and routing, then parameters. Each sentence adds value; no redundancy. Could slightly streamline parameter explanations but overall excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, description covers all parameters, usage variants, and practical advice. Missing output description but compensated by clear behavioral expectations. Adequate for agent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value beyond schema by providing examples, defaults, and contextual advice (e.g., including portfolio_url for self-qualification). Adds nuance like discovery_offer only used in counter route.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool declines spec work requests, with a specific verb and resource. It distinguishes from siblings like competitor_response_email, client_decline_email, and proposal_expiry_reminder_email by explaining each sibling's context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use each route (decline vs counter) and differentiates from sibling tools by describing their specific use cases, providing clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the three behavioral variations (routes) and the tone for each, along with the draft offer behavior. However, it does not specify whether the email is saved or sent automatically, which could be relevant for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured, with clear sections for each route and parameter context. It could be slightly more concise, but the detail is justified given the three distinct use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description does not explicitly state the return value, but it is implied that the tool generates an email draft. The parameter details are thorough, covering required and optional fields with examples. Overall, it is complete for the given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by providing context for the 'route' enum values, explaining implied behavior for 'offer_draft' on the after_completion route, and clarifying the purpose of 'platform_url'. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a testimonial request email and specifies three distinct routes (after_completion, specific_platform, delayed_ask). It differentiates from the sibling tool client_reference_request_email by noting it's for a written quote rather than a phone/video conversation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use each route, including the context for each. Additionally, it states the tool does not count against the monthly draft limit and distinguishes from a sibling tool, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It describes tone (professional, collaborative), content (targeted questions, explanations), and goal (prevent scope creep). It also notes it doesn't count against monthly draft limit. This is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and informative, but slightly longer than necessary. Every sentence adds value, making it efficient for its size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the email's purpose, tone, content structure, and differentiation from siblings. It covers all necessary context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds meaning beyond the schema: it explains how each parameter is used in the email (e.g., unclear_points become questions, suggest_call defaults true, response_deadline sets the timing). This is excellent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes an email for vague client briefs, asking clarifying questions. It explicitly distinguishes from scope_change_email and revision_response_email, making its unique purpose very clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (vague brief) and differentiates it from two siblings. It does not explicitly state when not to use it or list all alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It clearly implies a read-only check of usage data, with no modifications or side effects mentioned. Adequate for a status-check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully covers what the tool does, what it checks (drafts used/remaining), and when to use it. No missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters defined, baseline of 4 applies. Description does not need to add parameter info; the empty schema is fully explained by the simple check behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and resource 'free tier usage', and explicitly distinguishes from sibling tool 'draft_proposal' by advising to run this first if unsure of quota.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states to run before 'draft_proposal' when unsure of quota, but does not explicitly exclude other scenarios. Context is clear enough for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states it writes a draft email, but does not disclose whether it sends the email or if there are any side effects, auth requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four sentences) and front-loaded with the core purpose. Every sentence adds meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the relatively simple tool (no output schema, no nested objects), the description covers purpose, usage, parameter semantics, and behavioral constraints. It is sufficient for an agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions (100% coverage). The tool description adds value by explaining the effect of optional parameters (e.g., time_elapsed makes email less vague, value_hook adds timing context), beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool writes a re-engagement email to past clients, distinguishes it from two sibling tools (availability_announcement, reactivation_email), and specifies the target audience and tone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use criteria (past client, 6+ months gap) and contrasts with sibling tools. It also includes detailed content guidelines (acknowledge gap briefly, soft close) and states that it does not count against monthly draft limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's behavior: it can generate emails in two modes, and the sample_link parameter controls whether links are included or offered upon request. The description also clarifies that the tool does not consume a monthly draft limit, which is a behavioral trait not evident from the schema alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured, with a clear opening sentence followed by detailed explanations of modes and parameters. It uses bullet-like formatting for parameter descriptions, aiding readability. While it could be slightly trimmed, every section adds value and is well-integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary aspects: purpose, modes, parameter semantics, and a behavioral note about draft limits. Given the lack of an output schema, it conceptually describes the output as a professional email. The description is comprehensive for the tool's complexity and adequately prepares the agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the 100% schema coverage. It explains how each optional parameter enhances specificity, provides examples for sample_description, adjacent_work, and next_step, and clarifies the role of response_mode. This contextual information helps the agent craft highly tailored emails.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: writing a professional email responding to a prospect requesting work samples or portfolio pieces. It distinguishes two clear modes (have_samples and no_exact_match) and notes that it doesn't count against the monthly draft limit, setting it apart from sibling tools like cold_pitch or proposal_to_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each mode, with detailed explanations of the default (have_samples) and the alternative (no_exact_match). It explains the persuasive value of the no_exact_match mode. However, it lacks explicit 'when not to use' guidance or alternatives for other scenarios, such as when the prospect hasn't requested samples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the email's purpose, structure, and tone, and notes that it does not count against the monthly draft limit. However, it is somewhat ambiguous whether the tool actually sends the email or just generates the text, which could be clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is well-organized and informative, but slightly verbose. It efficiently conveys all necessary information without significant redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters, 3 required, and no output schema, the description comprehensively covers the tool's behavior, usage context, and output expectations. It includes comparison to siblings, structure guidance, tone, and a note about draft limits, making it fully adequate for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by explaining the context for parameters like 'reason' (one sentence max) and 'approval_needed' (default true). This goes beyond the schema definitions to guide the AI on proper usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes an email about a budget increase due to underestimation. It explicitly distinguishes from sibling tools like scope_change_email and budget_proposal by specifying the scenario of an honest estimate correction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance (honest update when estimate is off) and when-not-to-use (scope changes or budget proposals). It also outlines the recommended structure and tone, giving clear instructions for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It discloses behavioral traits: parks the prospect warmly, acknowledges inquiry, explains capacity, gives availability if known, offers priority slot. Also mentions it doesn't count against monthly draft limit. Missing: whether it sends or just generates the email text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs with front-loaded purpose. Every sentence provides useful information, no fluff. Could be slightly more concise but well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, parameters, and behavioral notes. Lacks explicit mention of output format (e.g., what the email text looks like) or error handling, but given no output schema, the description is fairly complete for a simple email generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds valuable context beyond schema descriptions, e.g., for project_description it clarifies 'makes the email feel specific rather than a generic I'm busy note.' Provides usage nuance for optional fields like available_from and offer_priority_slot.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional email to a prospect when fully booked, with a specific verb 'Write' and resource 'email', and distinguishes from sibling tools like client_decline_email and reactivation_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (fully booked but don't want to lose prospect), when not to use (permanent no), and names two alternatives (client_decline_email, reactivation_email). Also explains that it creates a warm pipeline rather than declining or going silent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the three routes with different tones, that it does not count against monthly draft limit, and explains the purpose of each parameter. However, it does not explicitly state that it only generates the email text and does not send it, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: starts with main purpose, then lists routes, differentiation, and parameter details. It is informative but not overly verbose. Could be slightly more concise, but front-loads key information effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, 2 required, no output schema, and no annotations, the description covers all necessary aspects: explains the three routes, gives examples, differentiates from siblings, and lists required and optional parameters with explanations. It is complete for an email generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by grouping parameters, explaining the route enum with examples, and providing context for each parameter (e.g., why you need access_reason). This extra semantic richness justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes an email to request access to client systems, tools, etc. It specifies the verb 'Write', the resource, and distinguishes between three routes. It also differentiates from sibling tools like client_material_chase_email and project_restart_email, making its purpose highly specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'For when you need logins, permissions, API keys, or repository invitations from the client side' and provides three distinct routes (initial_request, follow_up, partial_workaround) with clear contexts. It also contrasts with sibling tools, giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool produces an invoice (not a cover email or reminder), outputs Markdown, and includes a professional header, line items, subtotal, optional tax, and total. It does not mention any destructive actions or side effects, which is appropriate for a document generation tool. A minor gap is the lack of explicit statement about whether it modifies any records, but the context implies it is a pure generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is approximately 6 sentences, each conveying essential information without redundancy. It is front-loaded with the primary action, specifies the output format, distinguishes from siblings, and summarizes required/optional parameters. No fluff – every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, nested array for line_items) and lack of output schema, the description is remarkably complete. It explains the output format (Markdown) and content (header, line items, subtotal, tax, total). It also covers usage context and parameter guidelines. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the description adds significant value beyond the schema: it explains the purpose of each optional parameter (e.g., 'Omit to leave a placeholder' for invoice_number, 'Omit for fixed-fee items' for quantity/rate), provides examples for date formats, and clarifies the line_items structure. This makes parameter semantics very clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a complete, ready-to-send professional invoice document in Markdown format, and distinguishes itself from three sibling tools (invoice_cover_email, invoice_reminder, payment_plan_proposal). The verb 'Generate' and resource 'invoice document' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool ('Ideal for converting an accepted proposal into a billable document') and lists required and optional parameters. It explicitly distinguishes from sibling tools, though it does not explicitly state when not to use it (e.g., avoid for sending reminders). Still, the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It explains that the tool writes an email, details three behavioral routes, and mentions it does not count against monthly draft limits. It does not disclose if it saves or sends the email, but for a drafting tool this is sufficient. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with purpose and sibling distinctions. It efficiently explains routes and parameter semantics with examples. Though relatively long, every sentence adds value and is organized logically. Slightly verbose but earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 3 routes) and lack of output schema, the description is comprehensive. It covers purpose, usage guidelines, parameter details, and behavioral expectations. No gaps are apparent for an email generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value beyond the schema by providing examples, contextual advice (e.g., being specific in overrun_reason), and detailed route explanations. This enhances the agent's understanding of how to fill parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes an email for mid-project overruns due to underestimation, not client fault. It explicitly distinguishes from three sibling tools (change_order_email, scope_creep_email, project_delay_notification_email), making its purpose unique and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios (mid-project overrun due to underestimation) and when-not (client-requested changes, scope creep, timeline delay without cost). It also explains three routes with best-use contexts (revised_estimate for significant overages needing approval, propose_split for separable additional work, absorb for small overages).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the two modes of operation, the draft property (does not count against monthly draft limit), and provides details on how parameters affect behavior. The only minor gap is ambiguity about whether it actually sends or drafts, but overall it is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured: it opens with the core purpose, distinguishes from sibling, outlines common use cases, then explains modes and parameters. Every sentence serves a purpose, though some redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, two modes, and no output schema, the description covers all essential aspects: purpose, usage scenarios, parameter explanations (including examples), mode behavior, and the draft limit. It is comprehensive and leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining the reason_to_connect with a strong vs weak example, clarifying the use of person_a_description and person_b_description, and detailing the mode and target parameters with specific guidance. This goes well beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes the email when you are connecting two people in your network as the connector, not the person being introduced. It uses a specific verb-resource combination and explicitly distinguishes itself from the sibling tool introduction_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use double_opt_in mode (default, best practice for high-value relationships) vs direct mode (fine when you know both parties well and the intro is low-stakes). It also contrasts with introduction_email, providing clear usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tone (professional, not groveling), structure, and timing (before deadline passes). It does not mention destructive behavior or rate limits, but the non-destructive nature is evident. Could be more explicit about whether the tool sends or just generates the email.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: purpose, distinction from siblings, structure, and behavioral notes. Every sentence adds value without redundancy. It is concise given the amount of context provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers usage, structure, and tone well, but does not explicitly state what the tool returns (likely the email text). With no output schema, this is a minor gap. Overall, it provides sufficient context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining how each parameter fits into the email structure (e.g., reason should be one sentence, deliverable is optional). This enhances understanding beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool writes an email requesting more time on a project, and distinguishes it from similar tools like project_delay_warning and late_delivery_apology. The verb 'write the email' and resource 'requesting more time' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly defines when to use this tool vs alternatives: it's the middle ground between a warning (at risk) and an apology (already missed). It also states it does not count against the monthly draft limit, providing additional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description reveals important behavioral traits: it states the email is 'formal,' outlines three behavioral tones per route, and mentions it does not count against the draft limit. However, it does not explicitly clarify whether the tool sends the email or just generates text, leaving some ambiguity about the actual action performed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose, but it is somewhat lengthy due to detailed route explanations. Every sentence adds value, but could be slightly condensed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive for a complex tool with three routes and nine parameters. It covers all parameter usage and sibling differentiation. The only gap is the lack of explicit output description, but given the tool's name and context, the agent can infer it generates an email draft.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema. It maps each optional parameter to specific routes (e.g., outstanding_invoice for non_payment, missing_item for blocked_on_client), provides concrete examples, and explains the rationale behind default choices. With 100% schema coverage, this extra context is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a formal email pausing a project, specifies three distinct routes (non_payment, blocked_on_client, planned_pause), and explicitly distinguishes it from sibling tools like project_delay_notification_email, late_materials_impact_email, and project_scope_reduction_email. This makes the purpose highly specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each route, including defaults and alternatives. It also directly contrasts the tool with three sibling tools, telling the agent when not to use this tool. This level of detail fully equips the agent to select the appropriate tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits such as not counting against the monthly draft limit and describes the tone for each route. However, it does not specify any destructive actions or other side effects, which is appropriate for an email generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an initial purpose statement, route details, and parameter explanations. It is slightly verbose but every sentence adds value, earning a score of 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all seven parameters with examples, explains the three routes, and provides usage context. No output schema is present, but the description is sufficiently complete for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema, such as the default route, examples for first_step and timeline_note, and the purpose of each optional parameter, justifying a score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing a professional email to restart a paused project. It specifies three distinct routes and distinguishes the tool from siblings like project_kickoff_email and project_closure_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool (resuming a paused project), pairs with project_pause_email for lifecycle, and explains when to choose each of the three routes. It also differentiates from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool generates an email draft (implied by 'Write' and 'does not count against your monthly draft limit'), but does not explicitly state whether it sends the email or is read-only. However, the nature is clear and no contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise opening sentence, bullet-like coverage of email content, sibling differentiation, then parameter lists. Every sentence serves a purpose, and key info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8 parameters and no output schema or annotations, the description covers purpose, usage, parameter details, and a behavioral note (draft limit). It does not specify the return format, but that is acceptable without an output schema. Overall, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by grouping parameters into required/optional, providing real-world examples, and clarifying the purpose of each field (e.g., prime_name as 'name of the main contractor or agency'), going beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional email for accepting a subcontracting role, specifying the verb 'Write' and the resource 'email'. It explicitly distinguishes from three siblings (subcontractor_brief, bid_lost_follow_up, cold_pitch), leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for when to use (accepting a subcontracting role) and directly names three sibling tools as distinct alternatives. Also mentions that it does not count against monthly draft limits, adding practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the email is sent before departure, covers different routes with appropriate tones, and notes that it does not count against the monthly draft limit. It could mention more about sending behavior or potential side effects, but overall it provides key behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loading the purpose and then detailing routes and parameters. While it is somewhat verbose, every sentence adds value. It is efficient for the complexity of the tool without being padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, 2 required, and no output schema, the description comprehensively covers all parameters with examples and context. It explains the three routes, contrasts with siblings, and notes the no-draft-limit feature. It is fully complete for an AI agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds significant meaning beyond the schema: it explains the three routes in detail, provides examples for parameters like from_date and pre_absence_deliverable, and gives strong guidance like 'do not list a cover contact unless you have one'. This greatly aids proper parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes a proactive heads-up email before absence. It distinguishes three specific routes (vacation, conference_or_training, personal) and explicitly contrasts with sibling tools (project_pause_email, availability_announcement_email, project_delay_notification_email), making the purpose highly specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use (before going away) and provides detailed guidance on each of the three routes. It also distinguishes from sibling tools, telling what this tool is for and what it is not for. Required vs optional parameters are clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool's behavioral traits: it does not count against the monthly draft limit, imposes a 100-word body limit, and requires a gracious and brief tone. It does not mention any sending mechanism or permissions, but for a draft email tool, the provided transparency is sufficient beyond 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense paragraph but well-structured with clear sections: purpose, tone/length, sibling distinctions, and parameter details. It could be slightly more concise (e.g., bullet points) but is efficient and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully addresses the tool's complexity: it explains the scenario, required parameters, optional parameters with usage notes, constraints (100 words, tone), and relationship to siblings. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful context for each parameter (e.g., 'reason_if_known: what they told you — used to tailor tone', 'future_work_angle: a specific type of future work you'd like to be considered for'). It clarifies optional usage beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool creates a follow-up email after losing a bid, with a clear verb ('write'), resource ('professional follow-up email'), and context ('after you didn't win a competitive bid or pitch'). It also distinguishes this from sibling tools like cold_pitch_follow_up, client_followup, and no_response_closure_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance ('after you didn't win a competitive bid or pitch') and when-not-to-use guidance by contrasting with specific sibling tools, stating their distinct contexts (e.g., 'no response to a cold pitch' vs. 'actively told you they went with someone else').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It details behavioral traits: three response modes with clear definitions, no destructive actions, and the fact that it does not count against monthly draft limit. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized, front-loading the purpose, then explaining modes, distinguishing from sibling, and adding rationale and a bonus behavioral trait (no draft limit). Every sentence adds value without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 3 modes, no output schema), the description covers purpose, usage context, sibling differentiation, mode details, and a behavioral bonus. It is complete enough for an agent to understand when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and includes detailed descriptions for each parameter, including enum values. The tool description explains the three modes, which is already covered in the schema's enum description. While it adds context about when to use each mode, it does not add significantly new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing professional replies to critical/negative mid-project feedback. It specifies three response modes and explicitly distinguishes it from the sibling tool 'revision_response_email' for specific change requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool versus the sibling 'revision_response_email' by contrasting feedback types (qualitative/directional vs. specific change requests). It also advises against common pitfalls (defensiveness, over-apologizing) and promotes the intended professional path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers behavioral aspects: it generates a concise follow-up, resurfaces key hook, gives an easy out, asks yes/no, and mentions the draft limit. Lacks mention of any potential side effects or constraints beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose and key guidelines. Every sentence adds value; no redundancy. Efficiently communicates usage, tone, and sibling distinction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description still explains enough about output (short follow-up). Parameters are well-explained, and sibling tools are clearly differentiated. Completeness is high for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds context for days_since_pitch (calibrates tone) and new_angle (optional addition). Also clarifies that company_name personalizes subject line and original_pitch_summary is a one-sentence summary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it writes a short professional follow-up for unanswered cold pitches. Distinguishes from client_followup and win_back_email by specifying the exact scenario (genuine cold silence).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly defines when to use (cold pitch unanswered) and when not (post-proposal follow-up, re-engaging lapsed clients). Additionally provides a behavioral hint about not counting against draft limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool does not count against monthly draft limit and explains the two routes and their outputs. While it could state whether it drafts or sends the email, the behavioral details are sufficient for an email generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and scenario. Every sentence adds informative value, from the common mistake warning to the route explanation. It is efficiently structured without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters (2 required) and no output schema, the description covers all parameters with examples and context. It differentiates from a large set of sibling tools effectively. The email output is intuitive, so no further completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds value beyond the schema by explaining the routes in detail ('full_delivery... confident announcement...', 'early_preview... inviting feedback...'), providing concrete examples for deliverables, and clarifying optional parameters like original_deadline and feedback_window with usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Write the email when your work is ready ahead of the agreed deadline.' It explicitly distinguishes this tool from siblings like project_completion_email, project_handover_email, and milestone_approval_request_email, providing precise differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (work ready ahead of deadline) and when not to, contrasting with siblings. It also describes two routes (full_delivery and early_preview) with specific use cases, giving clear guidance on scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It explains the three functional routes and optional parameters that modify output, but does not explicitly state whether the tool sends the email or only drafts it. This slight ambiguity prevents a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but somewhat verbose, consisting of several sentences that could be tightened. However, it is well-structured with clear separation of routes and parameters, and front-loads the core purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description is remarkably complete. It covers all parameter details, explains each route's purpose, and provides examples, leaving little ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial value beyond the input schema, providing examples and context for each parameter (e.g., sample_description, results_to_share, portfolio_url, route). Schema coverage is 100%, and the description enriches understanding with concrete usage scenarios.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes an email asking for portfolio consent, specifies three distinct routes (add_to_portfolio, show_work_samples, full_case_study), and distinguishes it from sibling tools like testimonial_request_email and case_study_outline. The verb 'write' and resource 'email' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each route (lowest friction, specific approval, detailed breakdown) and explicitly contrasts with sibling tools. It also notes that the tool does not count against monthly draft limits, providing clear context for when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool does not count against monthly draft limits, which is a key behavioral insight. It describes the three routes and their conditions. However, it does not mention any authorization requirements, rate limits, or side effects (like whether it saves drafts or sends immediately). Given the email generation context, these are less critical, but still a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. It contains several sentences but all are informative. A slight reduction in length could improve conciseness, but the level of detail is justified given the complexity of three routes and multiple optional parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all aspects: what the tool does, when to use it (with alternatives), all input parameters with examples, behavioral notes (draft limit), and three routing options. There is no output schema, but the tool is straightforward (generates an email), so the return value is implied. The description is complete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning beyond the schema. It explains the purpose of each parameter with examples (e.g., objection_summary, alternative_scope), clarifies default behavior for route, and provides context on when to use optional parameters. This significantly enhances understanding for the AI agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing an email when a client objects to price. It distinguishes from sibling tools discount_request_response and budget_negotiation_email with specific differences. It also describes three distinct routes (hold_rate, alternative, walk_away), making the purpose very specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each route: hold_rate when confident in price, alternative when scope reduction works, walk_away when budget gap is too large. It also explains when to use this tool versus sibling tools, covering both when and when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the email covers next steps, timeline, and client needs. Could mention if the email is drafted or sent, but overall adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively long but well-structured, with front-loaded purpose, then route details, then parameter explanations. Every sentence adds value, though slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is very complete, covering all parameters, usage, and differentiation from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds rich context for each parameter, including examples (e.g., project_name: 'the Westbrook site rebrand') and usage notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes the email that officially starts a project, with three distinct routes. It distinguishes itself from sibling tools like working_agreement_email and proposal tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (after contract signed and deposit in), and when not to use (by distinguishing from other tools). Provides clear context for each route.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the email is proactive, offers a concrete proposal, and does not count against the monthly draft limit. However, it doesn't mention authorization needs or rate limits, which are less critical for a draft tool but still a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized, with a clear front-loaded purpose and structured route explanations. While every sentence adds value, it could be slightly more concise without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, 3 routes, many siblings), the description covers all necessary aspects: purpose, usage, parameter details, route options, and sibling differentiation. There is no output schema, but the description adequately explains the email's behavior, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value by explaining each parameter's role with concrete examples (e.g., reason examples like 'tracking 30% over budget due to unexpected API complexity'). It also clarifies default values and route-specific usage, going well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Write the email') and clearly identifies the resource ('proposing a scope reduction'). It explicitly distinguishes from sibling tools like scope_creep_email and budget_negotiation_email, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios ('catching it proactively... before it becomes a crisis') and when-not-to-use by contrasting with siblings. It also details three route options with clear use cases for each, offering actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses that the email does not count against a monthly draft limit and describes its strategy (keeps it short, gives memory prompt, optional focus). It implies a non-destructive write operation, but lacks explicit statements about reversibility or permissions. Still, it is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the core purpose and differentiation. Every sentence adds value: purpose, distinction from sibling, strategy for the email, and a key constraint (draft limit). No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not need to explain return values. It covers the email's purpose, usage scenarios, parameter guidance, and behavioral characteristics (no draft limit). For a simple email generation tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters have descriptions), so baseline is 3. The description adds extra meaning beyond the schema by explaining the strategic purpose of optional parameters: 'standout_result' is a memory prompt, 'focus_suggestion' makes writing easier, 'your_name' is for sign-off. This adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Write the email asking a happy client for a LinkedIn recommendation.' It uses a specific verb 'Write' and resource 'email,' and distinguishes itself from the sibling tool 'testimonial_request' by explaining the difference between a LinkedIn recommendation and a testimonial quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly differentiates this tool from 'testimonial_request' and explains when to use each. It also provides context on how to use the optional fields to make the ask easy, including a memory prompt and focus suggestion. This gives clear guidance on usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool 'writes' an email (implying draft generation) and that it does not count against a monthly draft limit. However, it does not explicitly state that it generates a draft (not sending) or describe any other side effects, though the context and sibling tools imply drafting. Minor gap, but still fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficient: it leads with the core purpose, then differentiates from siblings, explains routes, and details parameters. Every sentence adds necessary context without redundancy. The length is appropriate for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, usage distinctions, parameter semantics, and a key behavior (no draft limit). However, it does not describe the output format (e.g., that it returns a draft email text) or any potential side effects beyond the draft limit note. Given the tool's simplicity and the richness of other fields, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds substantial value beyond the schema by explaining the purpose and implications of each parameter (e.g., 'last_project keeps the email from feeling generic', 'time_sense: omit and the copy stays vague', route context for each enum). This makes the parameters much more meaningful for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing a re-engagement email to a past client. It distinguishes itself from three related sibling tools (cold_pitch, referral_request, testimonial_request) by highlighting differences in tone and intent, and explains three specific routes with their contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Excellent usage guidance: the description explicitly contrasts with cold_pitch, referral_request, and testimonial_request, telling the agent when to use this tool and when to use alternatives. The three routes (check_in, new_service, availability) are each described with their best-fit scenarios, providing clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It explains the tool generates email text and mentions it doesn't count against draft limit. Lacks details on potential side effects or permissions, but for a generative email tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with no redundancy. Every sentence adds critical context about modes, distinctions, and usage limits.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, all three modes, sibling tool differentiation, and draft limit. No missing context for an email generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. Description adds value by explaining how parameters relate to the three modes and which are used in each context, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool writes an email responding to a revision request and specifies three modes with clear explanations. It distinguishes itself from sibling tools, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with scope_change_email and scope_warning_email, and describes when each mode applies. Provides clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully covers behavior. It details the tone (professional, non-confrontational), structure (acknowledge, clarify boundary, offer change order/quote), and constraints (does not apologize). No destructive behavior is relevant; the tool drafts an email without sending.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences efficiently convey the tool's purpose, tone, and parameter list. Front-loaded with the main verb and context, every sentence adds value. Slightly longer than necessary but well-structured and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is thorough for a generative tool with no output schema: it covers purpose, behavior, parameters, and usage notes (no monthly limit). No missing critical information given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the tool description adds significant value by explaining parameter usage with examples (e.g., scope_change_description examples, purpose of optional fields). It clarifies how each parameter influences the output, exceeding schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing a professional, non-confrontational email for out-of-scope client requests. It explicitly distinguishes from siblings like scope_change_email and scope_warning_email, and provides specific context about the common freelancer situation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool (client request outside scope) and includes a note about not counting against monthly draft limit. However, it does not explicitly exclude alternative tools or provide when-not-to-use guidance, missing some comparative direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool does not count against the monthly draft limit and that it keeps the relationship warm, but does not clarify if the email is automatically sent or just drafted. The behavioral traits of the output (draft vs. send) are not fully specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two main sentences, front-loading the purpose and routes, then covering key details (distinctions, draft limit, required/optional params) efficiently. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters (4 required), no output schema, and no annotations, the description provides comprehensive context: explains all parameters' purpose, gives examples, names sibling alternatives, and clarifies a behavioral trait (draft limit). It is complete for the agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant value by explaining the role of each parameter in context of the three routes (e.g., what_can_be_cut for scope_reduction, middle_ground_offer for middle_ground) and providing examples of acceptable inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional email for a specific scenario (client budget shortfall) and outlines three strategic routes. It distinguishes itself from sibling tools by naming them (discount_request_response, competitor_response_email, change_order_email), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool (when client budget falls short), the three response routes with brief explanations, and explicitly distinguishes from sibling tools, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the email's content, tone, and required/optional fields. However, it doesn't clarify whether the tool drafts or sends the email, which is a minor gap. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet comprehensive; every sentence adds value. Front-loaded with purpose and usage, then parameter details. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a text-generation tool with no output schema. Covers why, when, what params, and alternatives. No gaps in explaining the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters are described in the schema with 100% coverage. The description adds value by listing required params, providing examples and defaults for each optional param, and giving practical usage tips beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes an email asking for sign-off on completed deliverables, and explicitly distinguishes it from three sibling tools (milestone_delivered_email, project_closure_email, project_completion_email) with concise differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context ('before you close the project or send the final invoice'), contrasts with siblings, and includes practical notes like 'Does not count against your monthly draft limit.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the behavioral logic: assumes good faith on first no-show offers reschedule, and politely closes on second no-show. However, it does not explicitly state whether the tool sends the email directly or outputs draft text, leaving a minor ambiguity about its exact action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: starts with core purpose, adds context, differentiates from siblings, and lists parameters with defaults. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and few sibling complexities, the description covers purpose, usage, parameters, and behavioral nuances comprehensively. It even notes the draft limit exemption, which adds helpful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3, but the description adds substantial meaning with examples (e.g., call_time: 'today at 2pm', no_show_count: defaults and scenario outcomes, reschedule_link: default behavior). This goes well beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes an email to a prospect who missed a discovery call. It explicitly distinguishes from siblings like meeting_cancellation_email, meeting_postponement_email, and cold_pitch_follow_up, and outlines the two scenarios (first no-show vs second no-show).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool vs alternatives by naming siblings and their contexts. It also notes that it does not count against a monthly draft limit, providing additional usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description covers behavioral aspects thoroughly: brief apology, instruction to disregard original, corrected details. It also notes it does not count against monthly draft limit and lists required/optional parameters. Since no annotations exist, this is fully comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but somewhat long. It is well-structured: purpose, comparisons, common mistakes, and parameter list. Could be slightly more concise, but no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers all necessary context: purpose, usage, behavior, parameters. It explains what the output (email) should contain and provides enough detail for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by grouping parameters into required and optional, providing examples, and explaining the role of each in the email. However, the schema descriptions are already detailed, so the added value is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a professional email to correct a sent invoice, distinguishing it from sibling tools 'invoice_dispute_response_email' (client disputes) and 'invoice_cover_email' (first send). It uses specific verbs and resources, and the title is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use (when you need to correct an invoice) and when not to use (dispute, first send). It also describes common mistakes, providing clear guidance on context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully discloses behavior: generates an email, does not count against monthly draft limit, requires specific inputs, and varies output by route. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded with purpose and differentiation. While verbose, every sentence adds value. Could be slightly trimmed but remains efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers tool purpose, usage, parameters, routes, and special behavior (draft limit). No output schema, but description implicitly covers return value (email content). Contextually complete for a tool with 7 parameters and 3 routes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value: explains how each parameter affects the email (what_discussed becomes recap, next_steps defaults, route changes tone, etc.), going beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool writes a follow-up email after a productive discovery call, with specific goals (confirm listening, recap key points, set next step). It distinguishes from sibling tools by naming them and contrasting their use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use guidance, including three routes (warm, interested_but_not_ready, send_proposal) and explicit differentiation from sibling tools like discovery_call_no_show_email and client_followup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It thoroughly explains the email structure (states what is delayed, why, mitigation, revised timeline) and tone (transparent, proactive). It also reveals a key behavioral detail: 'Does not count against your monthly draft limit,' which is valuable context for invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured paragraph. It front-loads purpose and differentiation, then covers structure and tone. It is concise with no unnecessary sentences. A minor deduction for slightly verbose phrasing in the sibling distinction, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters (3 required), no output schema, and no annotations, the description is remarkably complete. It covers purpose, usage guidelines, the structure of the generated email, tone, and an incidental behavioral feature (draft limit). No significant gaps remain for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: it explains how to use parameters like 'external_cause' ('naming the external cause clearly'), gives examples in parentheses (e.g., 'the payment gateway API'), and notes that 'revised_eta' should be omitted if unknown. This additional guidance elevates the score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing an email about a delay caused by an external dependency. It uses specific verbs ('Write the email'), names the resource ('client'), and explicitly distinguishes this tool from siblings like 'project_delay_warning', 'project_extension_email', and 'late_delivery_apology', which address internal delays or missed deadlines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (external delays) and when not to (own delay, extension, apology). It names specific alternative sibling tools for those cases, such as 'project_delay_warning' and 'late_delivery_apology', making the decision clear for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses key behaviors: tone calibration (friendly/firm/escalation), making impact clear without blame, and that it does not count against monthly draft limit. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five well-structured sentences, each adding value: purpose, usage, tone, sibling distinctions, and behavioral note. Front-loaded with main action. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (3 required), no output schema, and no annotations, the description thoroughly covers purpose, usage, behavioral nuance, and parameter explanations. It provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The overall description adds context on tone calibration and usage, but the individual parameter descriptions already provide semantics. Slightly redundant but still valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool writes a professional email for chasing overdue materials/content/approvals. Distinguishes from siblings like project_delay_warning, payment_reminder_email, and third_party_delay_email, providing specific verb+resource and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use: when client hasn't delivered committed items and delay blocks work. Mentions tone calibration based on overdue days and names alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it produces an under-150-word email, does not count against monthly draft limits, and follows a specific structure. No contradictions with missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but slightly lengthy; it could be tightened without losing clarity. However, it is well-structured and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description fully explains the tool's output (email), its workflow position, and behavioral constraints, making it complete for an agent to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters are described in the schema (100% coverage), and the description adds significant meaning beyond the schema, such as auto-formatting for what_discussed and fallback behavior for confirmed_next_step.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a follow-up email after a discovery call, providing a specific verb and resource. It distinguishes itself from siblings by explicitly differentiating from meeting_request_email and project_kickoff_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance (within 24 hours of a discovery call) and identifies alternative tools for different contexts, including the workflow sequence: meeting_request_email → call → this email → draft_proposal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully discloses behavior: generates a clear, confident update with matter-of-fact tone. Notes that it does not count against monthly draft limit. No hidden behaviors or contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but well-organized: opening purpose, sibling differentiation, tone guidance, parameter list with examples. Every sentence adds value, though could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema), the description covers all necessary aspects: when to use, tone, parameter examples, optional fields, and relationship to siblings. It is self-contained and leaves no ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant value by providing concrete examples for each parameter (e.g., 'Friday 20 June' for original_deadline) and explaining optional parameters' purpose (e.g., omit delay_reason for shorter email). This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Write) and resource (proactive email), specifying the exact scenario (when delivery is behind deadline, before client chases). It distinguishes from sibling tools by naming scope_change_email, client_waiting_email, and project_kickoff_email with their differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when YOUR delivery is running behind the agreed deadline — sent before the client has to chase you.' Provides alternative tools for different scenarios (scope change, client chasing, project kickoff), giving clear exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully handles transparency. It discloses that the email is short, warm, has one clear ask, no pressure, and does not count against the monthly draft limit. This is sufficient behavioral disclosure for a read-only email generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: purpose, differentiation, constraints, and a note about draft limits. No wasted words, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, 0 output schema, many siblings), the description is complete. It covers purpose, usage, constraints, and differentiation. The lack of output schema is acceptable as the tool generates an email, which is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The tool description adds framing (e.g., email will be warm, short) but does not significantly extend the parameter meanings. A score of 4 acknowledges the clear schema while recognizing the description adds useful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a short, warm email asking for referrals, and explicitly distinguishes it from testimonial_request, which asks for a written review. The verb 'write' and the resource 'referral email' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use for happy clients, differentiate from testimonial_request, and includes constraints (under 120 words, no pressure, doesn't count toward draft limit). It clearly tells the agent when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool writes an email, has three behavioral routes with default, and that it does not count against draft limit. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded purpose, followed by routes, sibling differentiation, and parameter details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, three routes, and no output schema, the description is remarkably complete. It covers all parameters, provides usage examples, and explains the three behavioral routes in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context like default values, route explanations, and example values for optional parameters, enhancing understanding beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: writing an email when a client exceeds revision allocation. It distinguishes from three sibling tools (revision_response_email, scope_creep_response_email, change_order_email), providing specific differentiators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use each of the three routes (notify_and_quote, offer_upgrade, close_and_decline) with scenarios. Also notes it does not count against monthly draft limit and distinguishes from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavioral traits: tone (warm, brief, non-pushy), handling of happy vs. unsatisfied clients, and optional parameters' effects. No contradictions with missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: first sentence states core purpose, then details tone, sibling distinctions, and parameter descriptions. No wasted words, all sentences add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description fully covers tool's purpose, usage, parameters, and behavior. It's complete for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters are described in the schema, and the description adds meaning: explains survey_link omission leads to direct reply, testimonial_ask adds a sentence, outcome_note personalizes email, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it's for writing a post-completion feedback email, distinguishing it from similar tools like bid_lost_follow_up, referral_thank_you, and cold_pitch_follow_up. Uses specific verb+resource structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (after completing a project) and names three sibling tools it's distinct from. Also notes it does not count against monthly draft limit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jabbawocky/proposalcraft'
If you have feedback or need assistance with the MCP directory API, please join our Discord server