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 requires an API key and has a free tier limit, but does not explain idempotency, overwrite behavior, or return value. The behavioral context is minimal for a mutation tool.

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

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

The description is two sentences with no fluff. It efficiently conveys purpose and a key prerequisite. However, it could be more structured by separating the purpose from the requirement.

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 five parameters (two required) and no output schema, the description lacks essential details about parameter usage, return values, and the 'Radar' concept. The tool's complexity requires more information for correct invocation.

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

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

Schema description coverage is 0%, and the description does not describe or provide meaning for any of the five parameters. Without compensating information, an AI agent cannot understand how to fill required fields like 'title' and 'url'.

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 saves a discovered event/community to the user's Radar in Your Echo Agent for specific downstream actions like calendar add, contact extraction, and AI-drafted outreach. It distinguishes from discovery tools (discover_events, discover_communities) and outreach drafting tools.

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 mentions the prerequisite ECHO_API_KEY and free tier limit, but does not explicitly state when to use this tool versus alternatives like extract_contacts_from_url or draft_outreach_for_event. It implies usage after discovery but lacks 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.

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals the tool is a one-shot operation with a maximum of 3 sources, indicating it is not for large-scale use. However, it does not specify whether the operation is read-only or has side effects, nor does it detail error behavior, rate limits, or authorization needs.

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

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

The description is extremely concise, consisting of two short sentences that front-load the core purpose ('One-shot lead list') and then briefly list the process and constraints. Every word adds value, with no filler or repetition.

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 lack of output schema and annotations, the description provides a reasonable overview but omits details like the number of contacts returned, error handling, and the exact role of the 'location' parameter. For a public demo tool, it is adequately complete, but lacks depth for production use.

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

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

The schema has 0% description coverage, so the description must compensate. It explains the purpose of 'niche' and 'category' by saying 'discovers communities for a niche+category', and clarifies the 'sources' parameter by stating 'max 3 sources'. However, it does not explain the 'location' parameter, leaving its meaning ambiguous.

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 builds a one-shot lead list by discovering communities for a niche and category, extracting contacts, and deduplicating. It specifies the output fields (name, title, company, email, location, source_url), making the purpose distinct. However, it does not explicitly differentiate from similar sibling tools like 'extract_contacts_from_url' or 'discover_communities', 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.

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

The description mentions 'Public demo — max 3 sources' which hints at a limitation but does not provide explicit guidance on when to use this tool versus alternatives. There is no discussion of prerequisites, scenarios where it is appropriate, or exclusion criteria 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.

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

Without annotations, the description carries full burden. It states the mutating actions but lacks details on side effects, permission requirements, or reversibility. Minimal behavioral disclosure.

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?

Extremely concise single sentence that front-loads the core purpose. Every word is necessary and no 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 low complexity (2 parameters, no output schema), the description is minimally adequate but lacks return value info, error cases, or prerequisites. Leaves some gaps.

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

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

Schema description coverage is 0%. The description adds value by listing the action enum values, but does not explain the job_id parameter. Incomplete parameter explanation.

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

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

The description clearly states the verb 'Pause, resume, or cancel' and the resource 'a running job', making the tool's purpose obvious. It distinguishes from sibling tools like get_job_status (read-only) and rate_job (rating).

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

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

No guidance on when to use this tool versus alternatives such as get_job_status for checking status. The description omits context about prerequisites or conditions for pausing, resuming, or canceling.

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?

With no annotations, the description carries full burden. It only states 'Public demo, no API key needed', implying it's a read-only demo endpoint, but does not disclose any behavioral traits such as data nature, rate limits, or side effects.

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

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

The description is very concise (two short sentences) but at the cost of missing important details. It is front-loaded with the main purpose, but could benefit from additional context without being verbose.

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 4 parameters, no output schema, no annotations, and multiple sibling tools, the description lacks critical information about return format, pagination, and data interpretation, making it incomplete for proper tool invocation.

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

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

Schema coverage is 25% (only location has description). The description lists category values but adds no meaning for niche or limit beyond the schema's enum and integer constraints. It does not compensate for the low coverage.

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

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

The description uses a clear metaphor 'Find where your audience gathers' and lists 12 specific community categories, making the tool's purpose immediately understandable. However, it does not differentiate from similar sibling tools like discover_events or find_linkedin_groups.

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

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

No explicit guidance on when to use this tool versus alternatives like discover_events or find_linkedin_groups. The phrase 'Public demo, no API key needed' gives a hint but does not provide decision criteria for tool selection.

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?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions DEMO MODE and a registration link for unlimited runs, but does not describe the output format, whether the tool modifies data, rate limits, or other side effects. The description is insufficient for an agent to understand behavior beyond basic discovery.

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

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

The description is two sentences, front-loading the purpose and following with demo mode info. It is appropriately sized with no wasted words, though the second sentence is somewhat promotional.

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?

With 3 parameters, no output schema, and no annotations, the description should explain what the tool returns and how it behaves in demo vs full mode. It fails to describe the return format (e.g., a list of events with key details) and only hints at limitations through the registration link. The description is not complete enough for an agent to fully understand capabilities.

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 67% (2 of 3 parameters have descriptions). The description adds context by listing event types (conferences, webinars, meetups, podcasts) which aligns with the 'kind' enum, but does not provide additional meaning for the 'limit' or 'niche' parameters beyond what the schema already states.

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 discovers live conferences, webinars, meetups, and podcasts in a niche, with a specific verb (discover) and resource (events). It distinguishes from sibling discover_communities by focusing on events rather than general communities.

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 mentions DEMO MODE works without an API key, providing a condition for use, but does not explicitly state when to use this tool vs alternatives like discover_communities or draft_outreach_for_event. Guidance is minimal beyond the demo limitation.

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?

With no annotations, the description carries the burden. It discloses the tool returns subject+body and is a demo, implying no sending or persistence. However, it doesn't mention any rate limits, authentication, or data handling, which would strengthen transparency.

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

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

Two sentences, no wasted words. First sentence states purpose and output format; second provides usage boundary. Efficient and front-loaded.

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

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

For a demo tool with moderate complexity (6 params, 3 required, no output schema), the description is nearly complete. It explains the purpose, output, and usage boundaries. Missing details on default tone or optional parameters like event_url slightly reduces completeness.

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

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

Schema description coverage is 33% (only sender_pitch and recipient_role have descriptions). The description adds overall context (e.g., event_name is the event reference) but does not detail each parameter 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.

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

The description clearly states the tool's specific action (generate a personalized cold email), the resource (referencing an event/community), and the output (subject + body). It distinguishes from siblings by mentioning it's a public demo and directing to an alternative for sending.

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?

Explicitly provides context: 'Public demo — for sending, deliverability, and reply triage, use Your Echo Agent.' This tells the agent when not to use this tool and what to use instead.

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?

No annotations are provided, so the description carries full burden. It discloses that the tool drafts emails (non-destructive) and includes public demo status, but does not detail side effects, auth requirements, rate limits, or storage behavior.

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

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

Two sentences provide a complete overview without fluff. The first sentence defines the core function, and the second enumerates draft components, making it easy to parse.

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?

Description covers the tool's output but lacks details on return format (no output schema), integration with sibling tools (e.g., when to use after 'build_contact_list'), and the meaning of 'Public demo' for usage constraints. Adequate but not comprehensive.

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

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

Schema description coverage is low (33%) with only the 'contacts' parameter having a meaningful description. The description fails to explain the 'sender' object structure or 'tone' enum options, leaving agents to infer from context. It adds minimal value beyond the 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?

Description clearly states the tool drafts personalized PR outreach emails per contact, grouped by source. It lists specific components (hook, pitch, reason, meeting ask, CTA), distinguishing it from sibling tools like 'draft_outreach_for_event' which targets events.

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

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

The description implies usage after building a contact list (mentioning 'From build_contact_list or user-supplied' in input schema), but does not explicitly state when to use this tool vs alternatives like 'draft_outreach_for_event' or 'queue_pr_outreach_job'. No exclusions or prerequisites are mentioned.

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?

With no annotations, the description bears full burden. It discloses the scraping action and extracted fields but omits important traits like rate limits, authentication requirements, error handling (e.g., invalid URLs), or destructive potential. The phrase 'Public demo' hints at limitations but is vague.

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 sentences efficiently convey purpose and outputs without waste. However, the structure could group behavioral notes or edge cases more clearly.

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

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

Given the tool's simplicity (1 param, no output schema), the description covers core functionality. However, it lacks details on return format, pagination, errors, or performance characteristics, leaving missing context for a scraping 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% (single param 'url' described as 'Any public URL.'), so baseline is 3. The description adds value by narrowing the scope to 'public event/community/organization page' and listing extracted fields, providing meaning beyond the 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 clearly states the action (scrape and extract structured contacts), the target (public event/community/organization page), and lists the extracted fields (name, title, company, etc.). It differentiates from sibling tools like discover_communities which focus on discovery rather than extraction.

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

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

The description implies usage for extracting contacts from public pages but does not explicitly state when to use this tool versus alternatives like discover_communities or draft_outreach. No exclusions or when-not-to-use guidance is provided.

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?

No annotations are provided, so the description carries full disclosure burden. It explains the multi-step behavior, conditional job saving with queue and ECHO_API_KEY, and the demo behavior returning only drafts. However, it does not mention potential side effects like actually sending emails outside of demo mode 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.

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

The description is extremely concise at two sentences. The first sentence front-loads the core purpose, and the second adds conditional behavior. No unnecessary words or filler.

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, nested objects, no output schema), the description lacks crucial details. It omits parameter semantics for sources and location, does not describe output format beyond 'drafts only', and fails to mention error handling or prerequisites like authentication beyond ECHO_API_KEY.

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

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

Schema description coverage is 0%, so the description must compensate. It explains niche, category, and queue, but fails to describe sources, location, and the detailed sender object fields (e.g., meeting_options, scheduling_link). Key parameters are left undocumented, requiring agents to interpret from the schema alone.

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: 'One-shot personalized PR outreach' and enumerates the steps (discovers communities, extracts contacts, drafts emails). It distinguishes from sibling tools like discover_communities and draft_pr_outreach_for_contacts by combining them into a single action.

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

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

The description implies usage for a combined workflow but does not explicitly state when to use it versus using the individual sub-tools (e.g., discover_communities, extract_contacts_from_url). It provides context for different modes (queue vs. public demo) but lacks explicit when-not or alternative comparisons.

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?

No annotations are provided, so the description must carry the burden. It discloses the assist-only requirement and TOS restriction, which is useful. However, it lacks details on rate limits, authentication needs, or what 'most active' means. The 'Public demo' note adds ambiguity about reliability.

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

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

The description is two sentences, front-loaded with the purpose, and each sentence serves a distinct function (purpose and behavioral note). No unnecessary words.

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

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

Given 4 parameters, no descriptions in schema, and no output schema, the description is insufficient. It does not explain what the tool returns, how parameters like 'limit' affect results, or what 'most active' means. The completeness is low for a tool with this complexity.

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 0% meaning no parameter descriptions in the schema. The description only implies the 'niche' parameter by saying 'for a niche'. It does not explain 'limit', 'region', or 'seniority', so it adds almost no value beyond the schema for 3 of 4 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?

The description clearly states the action 'discover', the resource 'LinkedIn Groups and professional associations', and the scope 'most active... for a niche'. It distinguishes from sibling tools like discover_communities and find_and_pitch by specifying the exact resource and the assist-only nature.

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

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

The description explicitly says 'Assist-only — you review + join manually (LinkedIn TOS forbids automation)', which provides clear context for when to use this tool (research/discovery) and implies not to use it for automated actions. However, it does not explicitly compare to alternatives or state when not to use.

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

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

No annotations provided, so description carries full burden. It states returns 2 short variants and mentions 'Public demo', but lacks details on permissions, rate limits, or potential side effects.

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

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

Two sentences convey purpose, context, output, and one notable feature (public demo). No filler, front-loaded with key verb and resource.

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

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

Given no output schema, the description minimally explains return (2 short variants) but lacks details on format, other outcomes, or error conditions. Could be more complete to aid understanding.

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

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

Schema coverage is 100%, so description adds minimal value beyond schema descriptions. The only extra is providing examples for the 'angle' parameter, which is helpful but not substantial.

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

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

The description clearly states the action (draft a comment), the resource (community thread), and distinguishes from siblings by emphasizing 'value-first' and 'before outreach'. Sibling tools like draft_outreach_for_event are for different contexts.

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?

Implied usage is for drafting comments in communities before outreach, but no explicit when/not-to-use or alternatives. Could better guide when to use this versus similar tools.

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?

With no annotations, description identifies the operation as a read ('Retrieve'), which is transparent. However, it does not disclose additional behavioral traits such as authentication requirements, rate limits, or whether 'agent_id' must match internal identifiers. Adequate 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.

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

Single sentence that is both concise and informative. No wasted words; structure is front-loaded with the key action and resource.

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

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

Given one simple parameter, no annotations, and no output schema, the description covers the tool's purpose well. It hints at output content (skills, pricing, modes, examples). Could mention return format explicitly, but current level is sufficient.

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?

Input schema has 100% description coverage for the only parameter ('agent_id'), so the schema already explains the parameter. The description adds no further meaning beyond 'Retrieve full card', so baseline 3 applies.

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 clearly states the action ('Retrieve') and resource ('full A2A agent card for one Echo Agent'). It distinguishes from sibling tools like 'list_available_agents' (lists all agents) and 'hire_echo_agent' (does hiring), by focusing on retrieving detailed card for a single agent.

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?

Description implies use when you need detailed card for a single agent, but does not explicitly state when to avoid using it or mention alternatives like 'list_available_agents' for browsing agents. Usage context is clear but lacks exclusion 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?

No annotations provided, so description carries full burden. It discloses that it returns status and other fields, implying a read-only poll. However, it does not mention idempotency, rate limits, or any side effects.

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

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

Single sentence with action verb 'Poll' and front-loaded return field list. Efficient, no redundant information.

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

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

For a simple tool with one parameter and no output schema, the description covers the main return fields but lacks context about when to call (e.g., after hiring), what 'progress' means, or how to use the returned data.

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

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

The only parameter, job_id, has no description in the schema (0% coverage) and the tool description adds no details about format, source, or validation 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 clearly states the tool polls a hired job and lists specific return fields (status, progress, etc.). It differentiates from siblings like control_job (which likely mutates state) and get_agent_card (which gets agent details).

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

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

No guidance on when to use this tool versus alternatives (e.g., control_job for changing state). Does not specify prerequisites like having a hired job first.

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?

With no annotations provided, the description carries the full burden. It discloses that the tool starts a campaign, returns a job_id, and that the agent performs specific actions. However, it does not mention side effects (e.g., email sending costs), idempotency, or failure behaviors.

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

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

The description is concise (two sentences) and front-loaded with the main action. It avoids unnecessary detail, but could benefit from a structured breakdown for complex parameters.

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

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

Given the tool has nested objects and 5 parameters with only 40% schema coverage, the description is insufficient. It does not explain the campaign object structure, sender identity requirements, spending cap semantics, or callback_url usage. The output is mentioned as a job_id but no schema exists, so more detail would help.

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 only 40%, so the description should compensate by explaining parameters. The description mentions the overall campaign process but does not add meaning to individual parameters like agent_id, sender_identity fields, or campaign.name/niche. The return value (job_id) is noted but not tied to any parameter.

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: hiring an Echo Agent to run an outreach campaign. It explicitly mentions key actions (finds leads, writes personalized emails, sends them) and distinguishes from sibling tools like list_available_agents or get_job_status.

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

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

The description implies usage for initiating an outreach campaign but does not provide explicit guidance on when to use this tool vs alternatives (e.g., when to use control_job or rate_job). No exclusions or prerequisites are stated.

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?

No annotations provided. Description implies read-only browsing but doesn't mention pagination, rate limits, or whether filters are exact match or substring. Adequate but not rich.

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 concise sentences. First summarizes purpose and output, second explains optional filters. No redundant or omitted information.

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

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

No output schema, but description lists key return fields. Lacks details on pagination, ordering, or result limits. Adequate for a simple filtered list 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 covers both params with descriptions. Description adds value by specifying filter type (substring) and giving example values (saas, ecommerce for niche). Clarifies optionality.

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?

Clear verb 'Browse' and resource 'Echo Agents available for hire'. Lists returned fields (id, name, description, pricing, skills). Distinct from siblings like get_agent_card (single agent) and hire_echo_agent (action).

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 use for browsing available agents with optional filters. No explicit when-to-use vs siblings or when-not-to-use. Lacks guidance on alternatives like search vs list.

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?

With no annotations provided, the description provides useful behavioral context: requires API key, uses verified sender, respects weekly caps, honors suppression list, routes replies. This goes beyond the schema but does not cover all traits like idempotency or error handling.

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

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

The description is three sentences, front-loaded with purpose and return values, followed by a prerequisite and behavioral details. Every sentence is necessary and adds value.

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 6 parameters, nested objects, and no output schema, the description is insufficient. It lacks explanations for most parameters, fails to describe the dashboard URL or how to use returned job_id, and does not mention output format.

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 only 17% (only 'groups' has a description). The description does not add meaning for most parameters (niche, notes, category, sender_identity details, spending_cap_cents). The description mentions 'verified sender identity' but does not clarify the sender_identity object's required fields beyond name and email.

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 saves PR outreach drafts as a job for review and send, and specifies return values (job_id + dashboard URL). It distinguishes from sibling tool 'draft_pr_outreach_for_contacts' by focusing on queuing rather than drafting.

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?

It explicitly requires ECHO_API_KEY and describes key behaviors (verified sender, caps, suppression list, reply routing). However, it does not explicitly state when to use this tool versus alternatives like 'draft_pr_outreach_for_contacts' or 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.

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

No annotations exist, so the description must carry full weight. It mentions 'submit' implying a write, but lacks details on authorization, idempotency, or side effects.

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

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

Single sentence, no redundancy, directly addresses the core purpose and parameter constraints.

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?

Adequate for a simple tool with no output schema, but missing prerequisites (job must be completed) and result description.

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

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

Schema coverage is 0%, so description needed to explain parameters. It explains stars range (1–5) and feedback optionality, but job_id is left implicit. Partial support.

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 explicitly states the action ('submit'), the resource ('job'), and constraints ('1–5 star rating with optional feedback'), clearly distinguishing it from sibling tools like control_job or get_job_status.

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

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

No guidance on when to use this tool (e.g., only for completed jobs) or when not to use it. No contrast with alternatives provided.

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