Skip to main content
Glama

scope_warning_email

Flag scope creep early by emailing clients when requests exceed the original brief. This proactive conversation helps confirm extra work or clarify scope, preventing surprise invoices.

Instructions

Write a professional email flagging scope creep BEFORE issuing a change order — the early-warning conversation that prevents the surprise-invoice moment. Use this when you notice a client requesting something beyond the original brief; it surfaces the issue collaboratively so the client can confirm they want the extra work (triggering a change order) or clarify it's within scope. Different from change_order (which documents agreed extra work and its cost); this is the conversation that comes first. Does not count against your monthly draft limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_nameYesThe client's first name
project_nameYesThe project name or description
original_scopeYesWhat was agreed in the original brief or contract (e.g. 'five-page website with a contact form', 'three rounds of copy revisions')
new_requestYesWhat the client is now asking for that falls outside that scope (e.g. 'an e-commerce shop with product pages', 'a complete brand refresh alongside the copy')
estimated_impactNoOptional: rough estimate of the time or cost impact — makes it concrete without being a formal invoice (e.g. 'roughly 6–8 additional hours', 'an additional £800–£1,200 depending on final spec'). Leave blank if you don't yet know.
your_nameNoOptional: your name for the sign-off
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/5

Is 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/5

Given 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/5

Does 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/5

Does 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/5

Does 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.

Install Server

Other Tools

Latest Blog Posts

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