Agent Safe Email MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds significant behavioral context beyond what annotations provide. While annotations declare read-only, non-destructive, idempotent operations, the description discloses pricing details ('$0.01/call for <=5 units'), token limits ('4000 tokens each'), quote requirements for larger threads, authentication method ('Via skyfire-api-key header'), and legal terms ('By using this service you accept the Terms of Service'). It also clarifies the service nature ('Advisory service only').

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded with the core functionality in the first clause. Each subsequent clause adds important operational details (pricing, authentication, terms). While slightly dense with multiple operational details, every sentence serves a distinct purpose without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's analytical complexity and the absence of an output schema, the description provides substantial context about what the tool does, its operational constraints, and behavioral characteristics. The annotations cover safety aspects well, and the description adds crucial operational details. The main gap is the lack of information about return values or analysis format, which would be helpful given no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema already fully documents the single 'messages' parameter with its structure, requirements, and constraints. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation without providing additional semantic context about the parameter's role in the analysis.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific verb ('analyze') and resource ('full email conversation thread') with precise analytical targets ('escalating social engineering, scope creep, and manipulation patterns'). It distinguishes itself from sibling tools like 'check_email_safety' or 'check_message_safety' by focusing on thread-level pattern analysis rather than individual message safety checks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool ('analyze a full email conversation thread') and implies usage through the mention of specific patterns. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the focus on thread analysis versus individual message checks provides some differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds valuable non-annotation traits: 'No AI call' (implementation method), 'no charge' (cost), 'instant response' (latency). Annotations already cover safety profile (readOnlyHint, destructiveHint), so description complements wisely with operational characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three efficient sentences: first defines I/O, second states cost/performance, third gives usage order. Front-loaded with value proposition, zero redundancy—every word earns its place despite marketing tone ('FREE').

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Rich schema (100% coverage) and clear annotations reduce description burden. Tool explains its ecosystem role ('call this first'), return format, and input flexibility sufficiently for a 22-parameter orchestration tool without output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage, so baseline is 3. Description adds crucial context with 'send whatever context you have' and concrete examples (draft replies, thread messages, image/video URLs), clarifying the flexible, all-optional nature of 22 parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states specific action 'triage' and output 'prioritized list of which security tools to run,' distinguishing it from sibling 'check_*' tools that perform actual security analysis. Positions it as a meta-tool that orchestrates the others.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit workflow guidance 'Always call this first to get the best security coverage,' establishing it as the entry point before specific security checks. Lacks explicit named alternatives or exclusion conditions, though 'first' implies temporal precedence over siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds significant value beyond annotations: discloses cost ($0.01/call), authentication method (skyfire-api-key header), and critical limitation ('Advisory service only'). Annotations already cover safety profile (readOnlyHint=true), so description appropriately focuses on cost/legal constraints rather than repeating safety traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with zero waste: purpose with timing constraint (sentence 1), cost/auth details (sentence 2), legal limitations (sentence 3). Front-loaded with core function. No redundant phrases despite covering legal, financial, and technical aspects.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensive for a single-parameter tool: covers purpose, cost, auth, and limitations (advisory nature). Minor gap: no output description given lack of output_schema, though 'Assess... for malware risk' implies the output domain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with complete property descriptions. Description references 'filename, MIME type, and size' which aligns with the schema's required fields, but adds no semantic depth beyond what the schema already documents. Baseline 3 appropriate for high-coverage schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Excellent specificity: 'Assess email attachments for malware risk' provides clear verb, resource, and scope. Specifies analysis based on 'filename, MIME type, and size' which distinguishes it from sibling tools like check_email_safety (full email) or check_url_safety (URLs).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear temporal guidance with 'BEFORE opening/downloading' establishing prerequisite timing. However, lacks explicit when-not-to-use guidance or named alternatives for cases where attachments might need check_media_authenticity or different analysis types.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial critical context beyond annotations: explicit cost ($0.01/call), authentication requirement (skyfire-api-key header), legal terms acceptance, and service disclaimer ('Advisory service only'). Also documents return values since no output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four well-structured sentences with no waste: purpose (1), return values (2), cost/auth (3), legal terms (4). Front-loaded with the core function. Dense but efficient given the operational details required.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Compensates well for missing output schema by describing return structure (verdict, risk score, threats, actions). Covers cost, auth, and legal requirements essential for external API tools. Could benefit from rate limit mentions, but otherwise complete for a 7-parameter analysis tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the schema adequately documents all 7 parameters. The description mentions no parameter details, relying entirely on the schema, which warrants the baseline score of 3 for high-coverage schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the specific action (Analyze) and resource (email) with detailed threat categories (phishing, social engineering, prompt injection). Distinguishes from siblings by specifying 'email' and 'AI agent' targeting, though it doesn't explicitly contrast with check_message_safety or check_response_safety.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides implied usage context by specifying the threat types detected and target audience (AI agents), but lacks explicit guidance on when to choose this over siblings like check_message_safety or check_attachment_safety. No '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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond annotations: it discloses pricing details ($0.04/image, $0.10/video via skyfire-api-key header), clarifies that results are 'best-guess estimates, not definitive', mentions Terms of Service acceptance, and labels it as an 'advisory service only'. Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior, so the description appropriately supplements rather than contradicts them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded with the core purpose. However, it includes some extraneous details like pricing breakdowns ('4 units x $0.01') and legal boilerplate ('By using this service you accept the Terms of Service') that could be streamlined while maintaining clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multi-layer analysis) and lack of output schema, the description does well by explaining the analysis methods (metadata forensics, error level analysis, etc.) and return format (confidence-scored verdict with per-layer breakdown). It could benefit from more detail on output structure, but it's largely complete for a tool with rich annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the schema already documents both parameters thoroughly. The description doesn't add specific parameter semantics beyond what's in the schema (e.g., it mentions 'image or short video' but doesn't elaborate on mediaUrl formats or mediaType implications). Baseline 3 is appropriate as the schema carries the parameter documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('analyze', 'assess') and resources ('image or short video'), distinguishing it from sibling tools focused on email, message, URL, or attachment safety. It explicitly identifies the analysis goal: determining if media is AI-generated, deepfaked, or authentic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (analyzing media authenticity) but doesn't explicitly mention when not to use it or name alternatives. It distinguishes from sibling tools by focusing on media rather than emails, messages, or URLs, though no direct 'vs alternatives' guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Superb disclosure beyond annotations: reveals cost ($0.01/call), authentication mechanism (skyfire-api-key header), external API dependency (consistent with openWorldHint), legal obligation (ToS acceptance), and critical limitation ('Advisory service only' clarifies this is analysis, not blocking action).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Information-dense with zero waste: front-loads core functionality (platforms and threats), follows with operational constraints (cost, auth, terms), and ends with scope limitation. Single-paragraph structure is slightly dense but highly efficient; every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Appropriately complete for a paid external service: covers invocation requirements (auth, cost), legal constraints, and safety limitations. Rich parameter documentation via 100% schema coverage compensates for lack of output schema, though brief mention of expected analysis output format would elevate this to 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline 3 applies. The description mentions the skyfire-api-key header requirement, which adds invocation context not in the JSON schema, but does not elaborate on input parameter semantics since the schema fully documents platform, sender, messages, and optional flags.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Excellent specificity: verb 'Analyze' targets 'non-email messages' with explicit platform list (SMS, WhatsApp, Signal, etc.) and threat taxonomy (smishing, OTP interception, crypto fraud). The 'non-email' qualifier effectively distinguishes from sibling tools analyze_email_thread and check_email_safety.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implicitly guides tool selection by specifying platform scope (non-email) and threat types, steering users away from email-specific siblings. However, it lacks explicit cross-reference to assess_message or check_response_safety for overlap cases, and omits when-not-to-use guidance beyond the advisory disclaimer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover read-only/idempotent/destructive hints. Description adds critical context beyond annotations: no authentication required, no charge, data source ('observed in the wild'), and specific return values ('injection patterns, payloads, threat classifications').

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences with zero waste. First sentence covers purpose, data source, and return values. Second sentence covers cost and authentication. 'FREE' prefix front-loads critical usage constraint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but description adequately covers return structure ('patterns, payloads, and threat classifications'). All 3 parameters are optional and well-documented in schema. Missing only explicit pagination/rate limit disclosure for openWorldHint tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% description coverage with clear enum values. Description mentions 'recent' (aligning with timeframe) and 'patterns' (aligning with type), but doesn't add syntax or format details beyond what the schema provides. Baseline 3 appropriate for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Query' with clear resource 'database of known prompt injection attacks'. Explicitly distinguishes from sibling safety tools by focusing specifically on prompt injection patterns from 'agent social networks', not general content safety.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly establishes use case: checking against observed prompt injection attacks to recognize manipulation. While it doesn't explicitly name sibling alternatives, the specific domain (prompt injection database) provides clear contextual differentiation from general message/email safety checks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, non-destructive, idempotent, and open-world hints. The description adds valuable context: cost ('$0.01/call'), authentication requirement ('via skyfire-api-key header'), and legal terms ('accept the Terms of Service'), which are not in annotations. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first clause, followed by cost, authentication, and terms in efficient sentences. Each sentence adds necessary information without redundancy, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, no output schema), the description is mostly complete: it covers purpose, usage context, cost, and authentication. However, it lacks details on output format or error handling, which would be helpful since there's no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all parameters. The description does not add any parameter-specific information beyond what the schema provides, such as explaining how 'originalBody' aids context. Baseline 3 is appropriate when schema handles parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Check a draft email reply BEFORE sending') and the resource ('draft email reply'), with explicit purposes: 'for data leakage, social engineering compliance, and unauthorized disclosure.' It distinguishes from siblings like 'check_email_safety' by focusing on draft replies rather than general email safety.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: 'BEFORE sending' indicates when to use it, and 'Advisory service only' clarifies its role. However, it does not explicitly state when not to use it or name alternatives among the sibling tools, such as 'check_email_safety' for non-draft emails.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Excellent disclosure beyond annotations: specifies live external checks (DNS DMARC, RDAP), cost per call ($0.01), authentication mechanism (skyfire-api-key header), and legal constraints (Terms of Service acceptance, advisory-only disclaimer). Annotations only declare safety/idempotency; description adds operational/business context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, zero waste: purpose first, technical implementation second, cost/auth third, legal disclaimer fourth. Front-loaded with value, no redundant fluff. Each sentence conveys distinct necessary information for tool invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensive given complexity: covers authentication, pricing, external dependencies, and service limitations (advisory-only). Lacks output format details, though no output schema exists to justify that requirement. Sufficient for an agent to understand side effects and costs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for all 5 parameters. The description adds context that DMARC/RDAP checks imply domain-level analysis but does not elaborate on parameter interactions or provide format guidance beyond the schema. Baseline 3 appropriate given complete schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verbs (verify, detect) and concrete threat types (BEC, spoofing, impersonation) clearly define the scope. The focus on sender identity distinguishes it from siblings like check_email_safety or analyze_email_thread which imply content or thread analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage through specificity (sender-focused verification), but lacks explicit when-to-use guidance or comparison to siblings. No mention of when to prefer this over assess_message or check_email_safety for general email analysis.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Excellent disclosure beyond annotations: specifies cost ($0.01/call), authentication mechanism (skyfire-api-key header), output structure (per-URL and overall verdicts), and legal constraints (Terms of Service acceptance, advisory-only disclaimer). Annotations cover safety profile (readOnly/idempotent), leaving these business/operational behaviors to the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences each earning their place: purpose, output, pricing/auth, and legal disclaimer. Information is front-loaded with the core function, followed by operational requirements. No redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single-parameter input (fully schema-documented) and lack of output schema, the description adequately covers the return values ('per-URL and overall verdicts') and provides critical invocation context (cost, auth key). Complete for a read-only safety check tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with the 'urls' parameter fully documented ('List of URLs to analyze'). The description mirrors this with 'one or more URLs' but adds no additional semantic details (e.g., URL format requirements, protocol constraints) beyond the schema's minItems/maxItems constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs ('Analyze') and resources ('URLs'), explicitly listing the threat types checked (phishing, malware, redirects, spoofing). The resource clearly distinguishes it from siblings like check_email_safety, check_attachment_safety, and check_media_authenticity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly differentiates usage by specifying 'URLs' as the target resource, but provides no explicit guidance on when to prefer this over siblings (e.g., check_email_safety for email content) or when-not-to-use scenarios beyond the 'Advisory service only' disclaimer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description states 'Submit feedback' which implies a write/mutation operation, but annotations declare readOnlyHint=true indicating read-only behavior. This is a direct contradiction. While description adds value with 'No authentication required' and 'No charge', the core operation type is obscured.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three efficiently structured sentences: value prop ('FREE'), action ('Submit feedback...'), and constraints ('No charge, no authentication required'). No waste, front-loaded with key info.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequately covers cost, authentication, and scope for a feedback endpoint. However, the readOnly/Submit contradiction leaves the actual side effects unclear. No output schema exists, but not required for a fire-and-forget operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, providing detailed descriptions for all 5 parameters (rating, checkId, comment, toolName, agentPlatform). Description mentions 'Agent Safe tool' which reinforces the toolName parameter purpose but adds minimal semantic detail beyond the already-complete schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verb 'Submit' with clear resource 'feedback' and explicitly scopes it to 'any Agent Safe tool you used', sharply distinguishing it from sibling analysis tools like check_email_safety or check_url_safety.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context signals ('FREE', 'No authentication required', 'Agent Safe tool') that establish when to use it (after using sibling tools) and prerequisites (none). Lacks 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.