TrendIdea

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds valuable context: it reaches the live web, runs AI extraction, costs 1 credit, and requires an https URL. This exceeds what annotations alone provide without contradiction.

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: the first delivers the core purpose and extraction details, the second provides usage guidance and critical constraints. No fluff, all information is immediately relevant.

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 (live web access, AI extraction, credit cost) and that an output schema exists, the description covers the key aspects: what it does, when to use, side effects, and constraints. It doesn't detail output fields, but the schema handles that.

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 parameters 100% with descriptions for url and language. The description reinforces the https constraint but adds no new semantic meaning beyond that. Baseline of 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 analyses a website URL, extracts specific elements (business model, target market, competitive advantage) and matches against TrendIdea data. This distinguishes it from siblings like get_moat_analysis which focus on existing ideas rather than external 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?

Explicitly states use case: 'Use it to profile a competitor or inspiration site before shaping your own idea.' While it doesn't mention alternatives or when not to use, the context is clear and actionable.

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?

Goes far beyond annotations. Describes side effects: spends credits based on VC score tier, exclusivity, non-reversibility, and lack of subscription requirement. The description explicitly states it is not read-only and not reversible, adding behavioral context beyond the destructiveHint and readOnlyHint 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?

Three sentences, all essential: purpose, key side effects, prerequisite check. No redundancy or filler. Front-loaded with the core action.

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

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

Given the presence of an output schema (so return values are covered) and comprehensive annotations, the description covers behavioral aspects, prerequisites, and consequences. It is complete for a high-stakes mutation tool with clear constraints.

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 baseline is 3. The description does not add new information about the parameters (ideaId or visibility) beyond what the schema provides. However, it implies the idea tier determines cost, which is not in the schema, but this is a minor addition. No parameter-specific detail is added.

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 'Claim' and resource 'marketplace idea', and specifies it adds exclusively to a portfolio. It distinguishes from siblings like create_idea or update_idea by highlighting exclusivity and credit cost.

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 says when to use: to claim an idea once per idea. Provides clear prerequisites: check get_credits_balance and idea tier. Distinguishes from alternatives implicitly by noting non-reversibility and credit spending, which is not present in read-only 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?

The description confirms the tool is not idempotent ('writes a new idea each call') and explicitly states 'Not read-only; it writes a new idea each call'. The annotations already set readOnlyHint=false, destructiveHint=false, so the description adds value by disclosing the non-idempotent behavior. It could mention if it requires authentication, but given annotations are present, this is well-handled.

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 long with no filler. It front-loads the core verb ('Create...'), follows with context vs sibling tools, then gives post-creation guidance. Every sentence adds value, and it is efficient for an AI agent 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?

Given the tool has 5 parameters (2 required, 2 enums) and an output schema that would cover return values, the description sufficiently explains the core behavior, entry-point role, and next steps. The mention of 'request_revalidation' as a follow-up adds completeness. It doesn't elaborate on error handling or defaults (e.g., visibility default), but those are in the schema. A slight deduction for not addressing how the output schema ties in.

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 the schema already documents all parameters well. The description mentions 'title and description' but doesn't add semantic detail beyond what's in the schema (e.g., no explanation of trendId linking, ideaType categorization, or visibility options). Baseline 3 is appropriate since schema covers the parameters completely.

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 uses the verb 'Create' with the resource 'brand-new startup idea' and specifies the inputs 'title and description'. It distinguishes itself from the sibling 'claim_idea' by explicitly stating 'rather than claiming one', 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.

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

The description explicitly states this is 'the entry point for building an idea from scratch' and provides clear post-creation guidance: 'run validation (for example request_revalidation) to get a VC score'. It also distinguishes from alternatives by highlighting it's 'not read-only' and 'writes a new idea each call', which helps agents decide when 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?

The description explicitly states it is not read-only and creates a shareable link record, which adds behavioral context beyond the annotations (destructiveHint=false). However, the conflicting statements 'read-only' vs 'Not read-only' reduce clarity on what the link actually permits, and no details are given about link expiration or access revocation.

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 with two actionable sentences plus one clarification. The key information is front-loaded. The contradictory note is brief but could be restructured to avoid confusion.

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 an output schema (which potentially describes the return value) and one simple parameter, the description covers the essential use case. However, the conflicting statements about read-only behavior create ambiguity about what permissions the link grants, and there is no guidance on whether the link is permanent or time-limited.

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

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

With 100% schema description coverage, the input schema already documents the single required parameter (ideaId). The description does not elaborate on parameter meaning beyond what the schema provides, so the baseline score of 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 generates a public, read-only share link for idea validation results, with an explicit use case (sharing with investors or teammates). However, it initially claims the link is read-only then contradicts itself with 'Not read-only; it creates a shareable link record,' which muddles the core purpose.

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 sharing results externally and mentions the audience (investors/teammates), but does not specify when to use this versus alternative sharing methods (e.g., grant_idea_access) or exclude inappropriate contexts like internal team sharing.

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?

Goes beyond annotations by explaining that deletion is permanent and irreversible, and specifying idempotent behavior as a no-op. 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.

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

Three concise sentences with no wasted words. Purpose is front-loaded. Each sentence adds essential information.

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

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

For a single-parameter destructive tool with an output schema and clear annotations, the description covers purpose, destruction, idempotency, and ownership scope. No gaps identified.

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 a basic parameter description. The description adds value by clarifying that `ideaId` must belong to the user ('one of your ideas'), which is an important usage constraint.

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 explicitly states the tool deletes an idea and its validation data. The verb 'permanently delete' distinguishes it from any sibling tool; no other tool performs deletion of ideas.

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 states it is destructive and should be confirmed before calling. Mentions idempotent behavior (no-op on already-deleted). Does not explicitly compare to alternatives, but there are no sibling delete tools, so guidance is sufficient.

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 discloses that the tool calls the LLM, incurs token costs, and is not read-only, which goes beyond the annotations (readOnlyHint false, idempotentHint true). It also adds an admin-only permission requirement, providing 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.

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

The description is two concise sentences: the first states the purpose, the second adds critical behavioral and permission caveats. No wasted words, front-loaded purpose.

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?

The tool is relatively simple with one parameter and an output schema. The description covers purpose, cost, read-only status, and admin restriction, making it complete for an agent to decide and invoke correctly.

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

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

Schema coverage is 100% and the leadId parameter is already described in the schema. The description adds no additional parameter-level detail, so it does not compensate beyond the baseline.

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 generates a personalised cold outreach pitch for a B2B lead using its diagnosis. It specifies a unique verb+resource combination that differentiates it from general content generation tools like generate_content.

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

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

The description implies the tool should be used when a B2B pitch is needed, and it contextually notes that it costs tokens and is admin-only. However, it does not explicitly contrast with alternatives (e.g., generate_content) or provide when-not-to-use scenarios.

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 discloses valuable dynamic behavior beyond annotations: returns cached canvas instantly if available, generates fresh analysis otherwise, charges one credit only for new content, and calls out non-read-only status. This gives the agent accurate expectations about side effects, costs, and performance.

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 front-loaded sentences cover purpose, behavior, cost, and prerequisite without padding. Every clause adds operational value for the agent.

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 is complete for a generation tool with an existing output schema and well-documented parameters. It tells the agent what to generate, how caching varies, how billing works, and what preconditions are required, leaving no major operational gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful ownership information with 'pass an ideaId you own' and links credit consumption to new generation, which helps the agent understand the ideaId as a user-scoped, side-effect-bearing input.

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 opens with a specific verb and resource: 'Generate a Business Model Canvas (Osterwalder) for an idea,' then enumerates the exact canvas components and synthesis. This clearly distinguishes the tool from siblings like generate_b2b_pitch and generate_strategic_review.

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 sets clear usage context by stating it operates on an idea and must be passed an owned ideaId. It also warns that it is not read-only, but it does not explicitly name alternative tools for other strategic outputs or describe when to choose this tool 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?

Beyond the annotations, the description discloses caching behavior, credit spending, and ownership requirement. It aligns with idempotentHint (cached content) and readOnlyHint=false, adding valuable operational details without contradicting any annotation.

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 tightly packed sentences, each contributing unique information: purpose, caching, cost, and usage requirement. No filler or repetition of schema details, and the primary action is stated first.

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 3-parameter tool with full schema coverage, an output schema, and rich annotations, the description covers purpose, behavior, cost, and prerequisites. It gives the agent everything it needs to decide to invoke and execute correctly, and the content type list in the schema covers the remaining specifics.

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 each parameter is already documented. The description adds the crucial constraint that ideaId must be owned, and reinforces the required contentType. This goes beyond the schema's basic 'The idea ID', providing meaningful usage context.

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 opens with a clear verb-resource pairing ('Generate ready-to-use marketing and business content') and enumerates specific content types, distinguishing it from the get_* read tools. While generate_b2b_pitch is a possible sibling, the description's scope is broader and unambiguous.

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 gives clear context for use (for an idea, with an owned ideaId and a contentType) and notes it's not read-only, but does not explicitly name alternatives or exclusions. The contextual info is enough to know when to reach for this tool, though it stops short of comparing against specific siblings like generate_b2b_pitch.

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?

Beyond the annotations (readOnlyHint=false, idempotentHint=true), the description discloses caching behavior ('Returns cached report instantly if one exists, otherwise generates fresh analysis'), cost ('Spends 2 credits only when generating new content'), and prerequisite data needs. No contradiction with annotations 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?

Three sentences, each dense with information: purpose, prerequisites, caching behavior, cost, and ownership caveat. No redundant phrases or filler. The description is front-loaded with the core function and progressively adds operational details.

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 output schema exists and the two parameters are fully documented, the description adds all necessary operational context: what data is synthesized, when to run revalidation, cached vs. fresh behavior, credit cost, and ownership requirement. It is complete for its scope.

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% for both parameters (ideaId and language), so the schema already documents them. The description adds value by specifying that ideaId must be owned by the caller, which is a meaningful constraint not present in the schema. It doesn't elaborate on the language parameter, but the enum and default in the schema suffice.

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 opens with a specific verb and resource: 'Generate an executive-level strategic review report for an idea,' and clarifies the output as a 'concise go/no-go assessment with actionable recommendations.' It synthesizes specific validation data types (market research, competition, SWOT, revenue model, VC score), distinguishing it from generic get_* and other generate_* sibling 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 explicitly states the prerequisite: 'Requires prior validation data (run request_revalidation first if none exists).' It also provides an ownership constraint ('pass an ideaId you own') and warns that the tool is 'Not read-only,' giving the agent clear context for when to invoke it versus when to seek data elsewhere.

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 says 'Read-only and free', which matches the annotation readOnlyHint: true. It goes beyond annotations by clarifying zero cost ('free') and automatic user scoping. There is 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.

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

Two concise sentences with maximum signal: first states purpose, second states when to use and constraints. No filler 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 zero parameters, a full coverage schema, annotations, and an output schema, the description fully covers what a zero-param read-only tool needs to enable correct invocation. It is complete.

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

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

The input schema is empty (100% coverage) and the description confirms it 'takes no parameters', which adds no ambiguity. No further param info is needed.

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

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

The description explicitly lists the verb 'list', the resource 'achievement badges', and the scope 'as a founder on TrendIdea'. It distinguishes itself from sibling tools like 'get_portfolio' or 'get_founder_dna' by focusing specifically on achievements and milestones.

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 states when to use it: 'to see progress and which milestones are still open'. It also clarifies that it 'takes no parameters and scopes to your own account', implying no filtering is needed. However, it does not explicitly mention when NOT to use it or name alternative tools for different scopes.

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 declare readOnlyHint=true and openWorldHint=false. The description adds significant behavioral context beyond annotations: it confirms the tool is free (no cost), requires admin privileges, and provides the specific fields returned. The annotations already signal a safe read operation, and the description enriches this with operational constraints that affect invocation decisions.

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, each earning its place: first sentence says what it does and what data it returns, second sentence explains the use case, third sentence declares constraints (read-only, free, admin-only). No filler words, front-loaded with the core action, immediately actionable.

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 a single required parameter (100% schema coverage) and an output schema (which renders return-value explanation unnecessary), the description is complete. It covers purpose, usage context, behavioral constraints, and parameter discovery. Nothing meaningful is missing for an agent to make an informed invocation decision.

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

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

Schema description coverage is 100%, so the schema already documents the single leadId parameter. The description adds minimal parameter-specific info (just that the leadId identifies a single lead), but the high coverage baseline is 3. The description suggests the leadId should come from a listing tool (list_b2b_leads), which adds indirect semantic value beyond the schema definition, justifying a 4.

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 ("Get the full detail") and names the resource explicitly ("single B2B lead"), listing the exact components returned (diagnosis, pitch, follow-ups, opportunity score). In the sibling list, there is a list_b2b_leads which lists leads, so get_b2b_lead clearly distinguishes itself as the detail-retrieval counterpart.

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 excellent usage guidance: it states when to use the tool ("before reaching out to a lead"), implicitly clarifies when not to use it (e.g., use list_b2b_leads to find leads first), and even specifies constraints ("Admin only") and safety properties ("Read-only and free"). This goes beyond basic purpose to actively guide agent decision-making.

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 declare readOnlyHint=true, so the description's added value is limited. However, it reinforces the read-only nature and adds the 'free' qualification (no cost), which goes beyond annotations. No contradictions are present. The description does not detail additional behavioral traits like rate limits or data freshness.

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 incredibly concise at two sentences, front-loading the core purpose and then providing 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.

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

Given the tool has only one simple parameter, full schema coverage, a clean annotation, and an output schema, the description is complete enough. It tells the agent what it returns (lead count, scout instructions), when to use it, and its safety profile. No gaps remain for the agent to be confused.

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

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

Schema description coverage is 100% with the parameter 'campaignId' already described as 'The campaign ID'. The description adds no further semantic detail about the parameter beyond what the schema provides, so it scores at the baseline of 3.

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 gets scouting info for a campaign, specifying exactly what that info includes: existing lead count and instructions for triggering new scouts. This distinguishes it from sibling tools like get_b2b_stats or list_b2b_campaigns which serve different purposes.

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 'Use it before kicking off a scouting run,' providing clear guidance on when to invoke this tool. It also labels the tool as 'Read-only and free,' which prevents misuse. However, it does not mention alternatives or when not to use it, keeping it from a top score.

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 supplements the annotations by confirming read-only behavior and adding that the tool is free and admin-only. This provides additional context beyond the structured annotations, such as cost and authorization requirements. 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?

Two sentences efficiently convey purpose, scope, and constraints. Every sentence adds value: the first states what it does, the second covers permissions and safety. No fluff or 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 no parameters and an existing output schema, the description covers the essential behavioral and access context. However, it lacks mention that this tool provides aggregated vs. detailed data, which would help agents decide between this and list siblings. Still, it is largely complete for a simple read-only endpoint.

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 zero parameters, the input schema is fully covered. The description adds meaningful context by listing the data categories (campaigns, leads, conversion rates) that will be returned. Since there is an output schema, detailed return value descriptions are not required. The baseline for zero-param tools is 4, and the description meets that.

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 it retrieves B2B lead engine statistics covering campaigns, leads, and conversion rates for a performance overview. The verb 'get' and resource are specific. However, it does not explicitly distinguish itself from sibling tools like list_b2b_campaigns or list_b2b_leads, which could also serve similar purposes but at a different granularity.

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 the many list-oriented siblings (e.g., list_b2b_campaigns, list_b2b_leads). The description only notes access restrictions (Admin only) and safety (Read-only), but fails to clarify that this tool provides aggregated overview data rather than raw lists, which is a key 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?

The description adds value beyond annotations: it confirms read-only (consistent with readOnlyHint: true), states it's free, lists supported builders, and clarifies that the output matches the in-app builder workspace. Annotations already cover the safety profile, so this additional context is useful.

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 (about 50 words), front-loaded with the main action, and includes all key information: purpose, output equivalence, supported builders, and safety/cost. No wasted or redundant words.

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

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

Given the tool has 3 parameters, annotations, and an output schema, the description covers purpose, output, supported builders, and read-only nature. It does not mention prerequisites (e.g., idea must exist) or error handling, but these are minor gaps for a tool with a clear read-only profile.

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% – each parameter has a description. The tool description repeats the list of supported builders already in the builderId parameter description, but does not add new semantic meaning beyond the schema. Baseline 3 is appropriate when schema already documents 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 tool generates a 'complete, builder-ready PRD and implementation guide' for turning ideas into apps with a specific AI coding tool. It specifies the verb 'Generate' and the resource 'PRD and implementation guide', and distinguishes itself from sibling tools like get_idea_summary or get_investment_memo by focusing on builder output.

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

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

The description implies usage context: when you want a prompt for a builder tool. It mentions supported builders and that it's read-only and free. However, it does not explicitly state when not to use this tool or compare it to alternatives (e.g., other get_* tools that produce different outputs).

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 declares 'Read-only and free; takes no parameters beyond an optional result limit', which adds useful behavioral context beyond the annotations (which already set readOnlyHint=true). It confirms the tool does not consume credits or require parameters, though it could mention response format or pagination behavior with an output schema present.

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, front-loading the core purpose and adding usage guidance without any wasted words. Every sentence serves a distinct purpose: purpose, usage, and behavioral traits.

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 only one optional parameter, an output schema (so return values are documented), and rich annotations (readOnlyHint, openWorldHint), the description provides complete context. It covers purpose, when to use, behavioral traits, and parameter usage. No gaps remain for this simple 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 already documents the 'limit' parameter well. The description adds context by calling it an 'optional result limit', which is helpful but not essential given the schema already provides rich details (default, max, min). A slight step above baseline 3 due to clarifying it is optional.

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 'Return your Chat Hub inbox' with specific resources ('recent AI coach conversations' and 'pending messages'). This provides a specific verb+resource combination that effectively distinguishes it from sibling tools like get_tasks or get_started.

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 tells when to use this tool ('pick up where an earlier coaching thread left off') and states it is 'Read-only and free'. It implicitly warns against using it for modifying data or paid access, effectively differentiating it from write tools like create_idea or update_idea.

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 declare readOnlyHint=true, and the description reinforces this with 'Read-only and free.' It adds value by disclosing the score composition (idea volume, VC score spread, claim rates) and the optional category filter. This goes beyond the annotation's safety profile to explain the tool's underlying behavior.

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

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

The description is two sentences with the core function front-loaded. Every clause earns its place: the metric definition, the use case, and the free/read-only note. 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?

With an output schema available, the description appropriately focuses on purpose and usage. It covers the key behavioral traits (read-only, free, category filter) and gives enough context to interpret the score. For a tool with two optional parameters and a clear output schema, this is complete.

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% for both parameters, with the schema already describing 'limit' as 'Max niches to return' and 'category' as 'Filter by idea type.' The description's mention of 'filter by category to focus one idea type' closely mirrors the schema, adding little new semantic meaning beyond what structured data already provides.

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

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

The description clearly states the tool measures competitive density using a specific score built from idea volume, VC score spread, and claim rates. It distinguishes itself from other analysis tools by focusing on saturation and openness of a niche, with an explicit use case before committing to an idea.

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

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

The description provides clear context on when to use the tool ('before committing to an idea') and how to focus it ('filter by category'). It does not explicitly name alternatives or when not to use it, but the context is clear enough for an agent to select it appropriately.

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 states 'Read-only and free', which aligns with the readOnlyHint annotation and adds the cost aspect. It also discloses that it 'takes no parameters and scopes to your own account', providing full behavioral context beyond the annotations. 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.

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

The description is exactly two sentences, front-loaded with the primary purpose. Every word serves a purpose: intent, usage timing, safety guarantee, parameter count, scope. No redundancy 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 this is a simple read-only tool with no parameters and an output schema present, the description covers all essential context: purpose, when to use, cost implications, parameter count, scope. The presence of an output schema means return value details are unnecessary per the rubric.

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 zero parameters and 100% schema coverage, the baseline is 4. The description explicitly confirms 'takes no parameters', which adds clarity beyond the empty schema. No need for further parameter detail.

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

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

The description clearly states the tool's purpose: 'Check your current credit balance and subscription tier'. This is a specific verb-resource combination that distinguishes it from the many other get_* tools in the sibling list, which deal with ideas, teams, b2b, market signals, etc. No ambiguity about what resource is being checked.

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 tells when to use: 'before running anything that costs credits' and 'to confirm you have enough budget for a claim, simulation or content run'. This provides clear context for invocation. It also implicitly scopes to the user's own account, indicating when not to use it (checking other accounts). No alternative tool exists in siblings, so no exclusion needed.

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 declare readOnlyHint and openWorldHint; the description adds meaningful behavioral context beyond annotations: the results are 'anonymous' and 'aggregated', the operation is 'free', and it requires the user to own the idea. No contradiction with annotations. Could be slightly more specific about what 'insights' include, but overall 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.

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

Two sentences with no filler. The first sentence states the core action and result; the second provides usage guidance. Every word earns its place. Highly concise 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?

Given that it has an output schema (covering return values), one parameter, and annotations that are well-aligned, the description is complete enough. It explains what the tool returns, when to use it, and the key precondition (owning the idea). No 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?

There is only one parameter (ideaId) with 100% schema coverage. The description adds critical extra meaning: 'pass an ideaId you own', which is not in the schema. This ownership constraint is essential for correct usage and goes beyond the minimal schema description.

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 specific verb 'Return' and a clear resource 'cross-user intelligence for an idea', and explains it provides 'anonymous, aggregated insights from similar ideas across the platform'. This differentiates it from sibling tools like get_similar_startups or get_competitive_density by focusing on aggregated insights rather than specific startup matches.

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 'Use it to learn how comparable ideas performed' and adds constraints: 'Read-only and free; pass an ideaId you own'. It provides solid context for when to use it but does not explicitly mention when not to use it or name alternatives like get_similar_startups, so it loses a point for lacking 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?

Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds 'Read-only and free', which aligns with the hint, and mentions data sourced from external sources. But it does not disclose additional behavioral traits (e.g., response format, pagination, or latency). Given the annotations carry the main burden, the description adds moderate 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?

Two sentences: the first defines the tool's output, the second gives usage and constraints. Everything is front-loaded, no extraneous words. Perfectly concise.

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?

The tool is simple (1 parameter, output schema exists). The description covers purpose, prerequisite (ownership), and safety (read-only, free). No missing 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?

The schema describes ideaId as 'The idea ID' with 100% coverage. The description adds the constraint 'pass an ideaId you own', which is meaningful context beyond the schema. This is valuable for correct invocation.

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 returns demand validation evidence including search trends, social signals, competitor funding, and market sizing. However, it does not explicitly differentiate from sibling tools like get_market_trends, get_social_proof, or get_competitive_density, which might overlap in content.

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

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

The description provides clear usage context: 'Use it to prove real demand exists before you build' and specifies prerequisites: 'pass an ideaId you own'. It does not mention when not to use it or alternative tools, but the context is sufficiently clear.

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 'Read-only and free; pass an ideaId you own' beyond annotations (readOnlyHint: true, openWorldHint: true). This clarifies cost implications and ownership requirement, which annotations don't cover. Slight deduction because it doesn't describe what happens if the ideaId doesn't exist or if domains are unavailable, but overall 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.

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

Two clear sentences, no redundant phrases, highly efficient. The first sentence states the core function, the second adds behavioral and usage context. Every word 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 the tool's simplicity (single required param, no enums, output schema exists, read-only), the description fully covers purpose, usage, and behavioral traits. The output schema handles return value documentation. No gaps remain for an agent to misinterpret this 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 description coverage is 100% with the ideaId parameter already described as 'The idea ID' in the input schema. The description adds no new parameter-level detail beyond the schema's existing description. Per guidelines, baseline is 3 when coverage is high, and no extra semantics are provided.

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

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

The description clearly states the tool returns domain name suggestions for an idea, specifying it covers available .com, .io, and .ai domains matched to the concept. It uses a specific verb ('Return') and resource ('domain name suggestions'), and distinguishes from siblings like get_pivot_suggestions or get_similar_startups by focusing on domain availability.

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 states when to use it: 'Use it to secure a name once you have decided to build.' This guides the agent to invoke it after concept validation, before domain purchase. No alternatives or exclusions are needed given the unique niche; the sibling list includes no other domain tools, making the guidance unambiguous.

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 declare readOnlyHint=true, so the read-only nature is covered. The description adds value by stating it is 'free' and clarifying that it returns empty if no reviews exist, plus the ownership constraint. This provides useful behavioral context beyond the 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 extremely concise: two sentences with no filler. The purpose is front-loaded, and every word adds value. It efficiently covers purpose, usage context, and behavioral notes.

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 read-only tool with two parameters and an existing output schema, the description covers all essential aspects: what it does, when to use it, preconditions, and return behavior. No gaps are apparent given the tool's complexity and available structured information.

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 both parameters described in the schema. The description adds extra semantics for ideaId by specifying ownership ('pass an ideaId you own'), which is not in the schema. Language parameter is not elaborated, but the schema already provides enum and default. Overall, the description meaningfully supplements 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 tool returns expert feedback for an idea, using the verb 'Return' and specifying the resource 'expert feedback'. It distinguishes from sibling get_* tools by mentioning 'qualified human judgement' and 'expert reviews', which is a unique function among the many get_ 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 provides clear context: use it to layer human judgement on an automated VC score, and it only returns data if expert reviews exist. It also implies a precondition (own the ideaId). However, it does not explicitly name alternative tools or state when not to use this tool, leaving some room for the agent to infer.

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 set readOnlyHint=true, so the description's 'Read-only and free' adds no new behavioral insight. The description adds that scores are 'derived from how you explore and validate ideas', which provides some behavioral context but not beyond what annotations already imply.

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, each earning its place: the first defines the output, the second explains usage, and the third adds convenience info. No wasted words, and critical information is 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?

The tool is simple (0 parameters, output schema exists). The description covers what it returns, why to use it, and that it's read-only and free. With an output schema present, no further explanation of return values is needed. The description is complete for its context.

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

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

The tool has zero parameters, and the schema description coverage is 100%. Per the baseline for 0 parameters, a score of 4 is appropriate. The description redundantly states 'takes no parameters' but adds no 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 tool returns a 'Founder DNA profile' with specific scores (risk appetite, innovation, market fit, etc.). The verb 'Return' plus the resource 'Founder DNA profile' is specific and distinguishes it from siblings like 'get_achievements' or 'get_idea_summary' which have different outputs.

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 suggests using it to 'personalise recommendations or understand your founder style', providing clear context. However, it does not explicitly exclude other tools or mention when not to use it, which is acceptable given the tool's simplicity and unique purpose.

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 value beyond annotations (readOnlyHint=true) by confirming the tool is 'free' and describing the result as 'raw output'. The parameter behavior (omit = all) is explained. No contradictions, but does not disclose potential pagination or size limits.

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 tightly packed sentences cover purpose, parameter usage, and guidance. No redundancy, all information is front-loaded and essential.

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 2 parameters with high schema coverage, an output schema, and clear annotations, the description provides sufficient context. It explains the raw vs summary distinction and the filtering options, making the tool self-contained.

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% and includes a full list of agent types. The description restates the filtering behavior ('zoom in on one agent' vs 'get every agent result') but adds no new semantic information beyond what the schema already conveys.

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 ('Fetch') and the resource ('raw output of AI agents that analysed an idea'), listing multiple agent categories. It distinguishes from the sibling tool 'get_idea_summary' by contrasting 'raw output' with 'headline numbers'.

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 tells when to use an alternative ('use get_idea_summary first if you only need the headline numbers') and explains the optional agentType parameter for zooming in or getting all results. Also clarifies the tool is 'Read-only and free', setting expectations.

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 provide readOnlyHint=true, so the description reinforces this with 'Read-only and free'. Adds behavioral context about ownership requirement ('pass an ideaId you own') and the nature of returned data (history of changes). 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?

Three sentences, each dense with useful information: purpose, use case, and constraints. No fluff or repetition. Front-loaded with the core action and then details.

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 there is only one simple parameter, a descriptive output schema, and full annotations, this description is fully adequate. It covers what the tool does, why to use it, and how to use it without 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 100%, so baseline is 3. The description adds value by explaining the parameter's purpose in context: 'pass an ideaId you own' clarifies the parameter must be an idea owned by the user, which is not explicit in the schema's minimal 'The idea ID' description. This extra context raises the score.

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

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

Description clearly states the tool returns 'full evolution history of an idea' with specific examples like 'VC score changes over time, edit history and version tracking'. It distinguishes itself from sibling get_* tools like get_idea_timeline and get_improvement_synthesis by focusing on evolution history.

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?

States when to use it: 'to understand how an idea has improved or drifted since creation'. Also notes it is 'Read-only' and 'free', and specifies requirement: 'pass an ideaId you own'. No explicit when-not-to-use or alternatives, but the use case 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.

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

The description states the tool is 'Read-only and free,' which adds value beyond the readOnlyHint annotation by also noting cost implications. It mentions passing an ideaId 'you own,' implying authorization requirements. There is 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.

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

The description is two concise sentences: first explains what the tool returns, second explains when to use it and prerequisites. Every sentence adds value without redundancy or unnecessary detail.

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 an output schema, the description doesn't need to explain return values. It covers purpose, usage context, and authorization hints. The single required parameter and good annotations make this description 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.

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

The input schema already has 100% description coverage for both parameters (ideaId and language). The description mentions passing 'an ideaId you own' but doesn't add new meaning beyond what the schema provides, so a baseline score of 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 retrieves a 'full validation dossier' for an idea, listing specific components like VC score, market research, and competition. This distinguishes it from siblings like get_market_trends or get_competitive_density, which focus on individual aspects.

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 to use this tool 'first when you need the complete picture of an idea before deciding what to do next.' It also instructs to find an ideaId using list_my_ideas, providing clear when-to-use and prerequisite 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 states it is 'read-only and free', which adds value beyond the readOnlyHint annotation (true) and openWorldHint (false). It reinforces the safety profile and adds cost information (free) not present 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 three sentences long, each adding unique value: first explains what the tool does and its output, second states its use case (audit), third provides safety and ownership guidance. No wasted words, front-loaded with the core purpose.

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 an output schema (so description need not explain return values), only one required parameter, no enums, and annotations already cover read-only and open-world hints, the description is complete. It additionally provides ownership scope and cost/free status, which are not in the structured 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?

Schema description coverage is 100% and there is only one parameter (ideaId) with a basic description 'The idea ID'. The description adds no additional parameter semantics beyond what the schema provides, but with complete coverage and a simple schema, the baseline of 3 is elevated to 4 because the description is clear enough that no extra parameter detail is needed.

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

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

The description clearly states the tool returns the full validation timeline for an idea with all events in chronological order, including agent runs, simulations, and score changes. It explicitly distinguishes this from other tools by specifying the scope (full timeline, chronological, audit-focused) and names specific event types.

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 when to use it ('audit exactly what happened to an idea and when') and provides a constraint on usage ('pass an ideaId you own'). While it doesn't explicitly name sibling alternatives, the context makes it clear this is the go-to tool for chronological audit of an idea's events, distinguishing it from other get_* 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?

Annotations already declare readOnlyHint=true, so the description's 'Read-only and free' adds no new transparency there. However, it adds value by noting the idea must be 'already validated' and owned, and by explaining the tool's internal approach (combining corpus benchmarking with VC scoring). 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 two sentences: the first states purpose and output, the second tells when to use and constraints. Every word earns its place with no redundancy. Front-loaded with key value proposition.

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?

The tool has an output schema (not shown but noted present), so the description doesn't need to explain return values. It covers purpose, usage context (validated owned ideas), and safety (read-only, free). With 2 simple params and full schema coverage, this is complete.

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 baseline is 3. The description adds value by implying that ideaId must refer to a validated, owned idea, which goes beyond the schema's bare 'The idea ID'. It also implies language is a response format choice, aligning with the enum. This extra context justifies a 4.

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 returns 'AI-powered improvement suggestions for an idea' that combine 'corpus benchmarking with VC scoring insights into concrete next steps'. The verb 'Return' and resource 'improvement suggestions' are specific, and 'concrete next steps' distinguishes it from other get_* tools like get_validation_snapshots or get_expert_feedback.

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 says when to use it: to 'understand exactly what would raise an idea score'. It also provides context: 'pass an ideaId you own that has already been validated'. However, it doesn't explicitly exclude alternatives or mention when NOT to use it compared to siblings like get_pivot_suggestions.

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 declare readOnlyHint=true and openWorldHint=false. Description adds that it is 'Read-only and free', which reinforces safe behavior. It also clarifies the data source (validated ideas) and that the output includes specific sections.

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: first defines purpose and content, second explains use cases and constraints. Every word adds value, no fluff, front-loaded with key information.

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

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

Given the tool has output schema (not shown) and only 1 simple parameter, the description adequately covers purpose, prerequisites, and behavioral traits. Slight gap: no mention of what happens with invalid or unvalidated ideaId, but overall 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?

Schema coverage is 100% with a clear description for ideaId. The description adds context about the idea needing to be validated and owned by the user, which goes beyond the schema's 'The idea ID' but the parameter semantics are minimal and schema already handles it.

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 specifies verb 'return', resource 'VC-style investment memo', and content (thesis, key risks, comparable exits, recommendation). It clearly distinguishes tasks like generating pitches (generate_b2b_pitch) or summaries (get_idea_summary).

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 states when to use: 'present an idea to investors or to pressure-test your own conviction'. Also provides prerequisite: 'pass an ideaId you own that has been validated', which improves usage 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?

Annotations already declare readOnlyHint: true, so the description doesn't need to re-state safety. The description adds value by clarifying that the tool is 'free' (no cost) and requires an owned ideaId. It also broadly describes what the analysis covers (momentum, timing, opportunity). 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 extremely concise at just two sentences, each adding distinct value. The first sentence states the purpose and content, the second covers usage guidance and constraints. No filler or repeated information from structured fields.

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 that there is an output schema (though not shown in detail), the description is appropriately complete: it explains when to use, what the return covers, and the ownership constraint. The only minor gap is no mention of pagination or rate limits, but that is acceptable for a single-parameter read-only 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 description coverage is 100% (the only parameter 'ideaId' is described). The description adds that the ideaId must be owned by the user, which marginally enhances the schema's bare description. Since coverage is high, a baseline of 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 states exactly what the tool does: 'Return market signal analysis for an idea', specifying key components 'trend momentum, timing analysis and market opportunity indicators'. It clearly distinguishes itself from sibling tools like 'get_market_trends', 'get_demand_proof', and 'get_competitive_density' by focusing on the holistic signal analysis for a single idea.

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 guidance: 'judge whether now is the right moment to pursue the idea' and notes it is 'Read-only and free'. It also imposes the precondition 'pass an ideaId you own'. However, it does not explicitly state when NOT to use this tool or mention any alternatives among the many 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?

Annotations already provide readOnlyHint: true. The description reinforces this with 'Read-only and free', adding the 'free' aspect which is not in annotations. It does not mention response limits or pagination, but the output schema likely covers structure. The behavioral context beyond annotations 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.

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

The description is two sentences, front-loaded with purpose and value, followed by filtering guidance and pairing suggestion. Every sentence is essential, with no wasted words. Excellent conciseness.

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 only two optional parameters, an output schema, and sibling context, the description is largely complete. It covers purpose, filtering, pairing, and safety (read-only). A slight gap is not explaining what 'velocity' means, but that is likely in the output schema. Overall very solid.

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 both parameters are documented. The description adds value for the category parameter ('Filter by category to focus a sector, or omit it for the overall board'), but does not elaborate on 'limit'. The added context for one parameter moves it slightly above baseline 3, but not enough to reach 4.

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 shows 'startup categories that are trending right now and their velocity', providing a specific verb (Show) and resource. It distinguishes itself from siblings like get_sector_report by mentioning deeper drill-down, so the purpose is well-defined and unique.

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 gives clear guidance on when to use: 'Filter by category to focus a sector, or omit it for the overall board' and pairs with get_sector_report for deeper analysis. It does not explicitly state when not to use it, but the context is sufficient. Minor improvement would be to exclude overlapping tools like get_market_signals.

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 mark the tool as read-only. The description adds value by stating it is 'free' and requires an 'ideaId you own,' providing ownership constraints beyond the structured data. It does not contradict annotations (both indicate no side effects). While it could disclose more about rate limits or caching, the added context is helpful.

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: two sentences, both front-loaded with essential information. The first sentence defines the output, the second provides usage and constraints. No unnecessary words 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 tool's simplicity (1 required param, no enums, output schema exists), the description covers the key points: what the analysis includes, why to use it, and the ownership requirement. It does not explain the data source or refresh behavior, but this is minor for a straightforward read 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?

With 100% schema description coverage for the single parameter, the baseline is 3. The description goes beyond by specifying that the ideaId must be owned by the caller ('you own'), adding meaningful usage context that the schema alone does not convey.

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 returns a 'competitive moat analysis' with specific components (defensibility, barriers, moat strength), and explains its purpose: understanding how hard an idea is to copy. It distinguishes itself from sibling tools like get_competitive_density and get_market_trends by focusing on defensibility, but does not explicitly differentiate itself from other analysis 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 provides a clear usage scenario ('understand how hard the idea would be to copy once launched') and a prerequisite ('pass an ideaId you own'). However, it does not mention when not to use this tool or suggest alternative tools from the sibling list, leaving the agent without 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?

Annotations already declare readOnlyHint=true. The description adds 'free' (cost context not in annotations) and 'pass an ideaId you own' (auth requirement). No contradictions; description supplements annotations with useful 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.

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

Two sentences, front-loaded with purpose, no wasted words. Every sentence adds useful information: what it does, when to use, and key constraints. Excellent conciseness.

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 (one required parameter, full schema coverage, existing output schema) the description adequately covers all necessary context: purpose, usage scenario, ownership requirement, and cost/safety profile. Nothing important is missing.

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% ('The idea ID'). The description adds 'you own' which implies ownership constraint, adding mild semantic value beyond the schema. Baseline is 3 per rules; the small addition does not warrant a higher score.

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

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

Description clearly states the verb 'Return' and the resource 'AI-generated pivot directions for an idea', specifying the bases (market gaps, competitive landscape, trend momentum). Among many sibling get_* tools, this one uniquely addresses pivoting, so it is well-distinguished.

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 tells when to use: 'when an idea scores poorly or the market looks crowded and you want fresh angles.' Also mentions ownership requirement ('pass an ideaId you own') and that it's read-only and free. Lacks explicit 'when not to use' or alternative tool names, but the positive guidance is strong.

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 provide readOnlyHint=true, but the description adds context: 'Read-only and free; takes no parameters and always scopes to your own account.' This goes beyond the annotation by describing scoping and parameter behavior, fully disclosing the tool's safe, non-destructive nature.

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, front-loaded with purpose in the first sentence, and usage context in the second. Every word earns its place; no fluff or repetition. Ideal length for a zero-parameter tool.

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

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

Given the tool's simplicity (no parameters, read-only, output schema exists), the description covers all necessary context: what it returns, when to use it, and its safety profile. The output schema handles return structure, so no need to detail that further.

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 zero parameters and 100% schema description coverage, the baseline is 3. The description only confirms 'takes no parameters', which is already evident from the schema. No additional semantic value is added beyond what the schema provides.

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

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

Description clearly states 'Return your complete idea portfolio in one view' and specifies exact contents (VC score, build status, type). It distinguishes from siblings by framing it as a 'founder-level overview before drilling into a single idea', which differentiates it from other get_* 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?

Explicitly tells when to use: 'Use this for a founder-level overview before drilling into a single idea.' Also notes it's read-only and free, which helps in decision-making. While no 'when not to use' is stated, the guidance is clear and sufficient for the tool's simplicity.

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 declare readOnlyHint=true, and the description reinforces 'Read-only and free', confirming no side effects. It also adds a critical behavioral constraint: 'pass an ideaId you own,' which informs the agent about access permissions beyond what the schema provides. 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.

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

The description is two short sentences with no wasted words. The first sentence states what the tool returns, the second provides usage guidance. Every sentence adds distinct 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 the tool has only one parameter, has an output schema (so return values are documented separately), and annotations cover safety, the description fully covers what an agent needs: purpose, usage guidance, the fact it's read-only and free, and the ownership requirement. No 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 coverage is 100% with a single parameter (ideaId) described in the schema. The description adds meaningful context by stating the ideaId must be owned by the caller, adding a usage constraint not in the schema. This provides value beyond the base baseline of 3.

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 returns a revenue projection for an idea, specifying three concrete elements: financial model, growth scenarios, and unit economics. This directly distinguishes it from tools like get_competitive_density, get_market_signals, get_moat_analysis, and other get_* siblings that return different types of analyses about an idea.

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 advises when to use this tool: 'Use it to sanity-check whether the business can make money before investing further.' This gives clear context. However, it does not explicitly mention when NOT to use it or name alternative tools for other financial checks, such as get_investment_memo or get_founder_dna.

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 declare readOnlyHint=true, and the description reinforces this with 'Read-only and free.' It adds the cost signal 'free,' which is helpful for an agent. No contradictions. While it doesn't detail rate limits or response size, the output schema covers return structure, so the description adds reasonable extra context.

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

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

The description is three sentences with zero waste. The first sentence immediately lists the report contents, the second gives the use case, and the third adds cost/access notes. It is front-loaded and every sentence earns its place.

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

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

Given that an output schema exists, the description does not need to explain return values. It covers purpose, usage context, and inputs sufficiently. For a two-parameter tool with annotations and output schema, this description is complete.

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 both parameters (sector and language) already described in the input schema. The description only mentions 'pass a sector name or category label' and gives examples that are duplicated from the schema. It does not add new parameter semantics beyond what the schema provides, 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.

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

The description clearly states the tool 'Produce a complete sector or industry report' with a specific list of contents (total ideas, average VC scores, competitive density, etc.). It differentiates from siblings like get_competitive_density or get_market_trends by offering a comprehensive aggregated report, not a single metric.

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 recommends using the tool 'to size up a whole market before picking an angle,' giving clear context for when to invoke it. It does not explicitly state when not to use it or name alternatives, but the provided use case is sufficient 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?

Annotations already provide readOnlyHint=true and openWorldHint=true, so the tool is known to be safe and potentially returns external data. The description adds that it uses the 'TrendIdea database and external sources' and requires an 'ideaId you own'. It does not contradict annotations. The description adds some value beyond annotations but does not disclose limitations or fallback behavior.

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

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

The description is three sentences long, each sentence carries distinct weight: the first states the primary function and data sources, the second explains the purpose, and the third adds usage constraints. No word is wasted, making it 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?

Given the tool has one required parameter with full schema coverage, an output schema (available), and clear annotations, the description is adequately complete. It could optionally explain what the output contains, but since an output schema exists, this is not required. The description provides sufficient 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.

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

The input schema already provides a description for the single parameter ('The idea ID'), and schema description coverage is 100%, so the baseline is 3. The description adds that the ideaId should be one 'you own', which is a useful constraint not in the schema. This justifies the baseline score.

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

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

The description clearly states the tool finds 'similar startups and competitors for an idea', using a specific verb ('find') and resource ('similar startups and competitors'). It distinguishes itself from siblings by mentioning the specific use case of mapping the competitive field and finding comparables for benchmarking, which is unique among a large set of 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 provides clear context for use: mapping the competitive field and finding comparables for benchmarking. It also states that it's 'Read-only and free', implying it can be used without constraints. However, it does not explicitly list when not to use it or mention any alternatives among the many 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?

Annotations already declare readOnlyHint=true, and the description adds 'Read-only and free' plus 'pass an ideaId you own'—extra context about cost and ownership. It also discloses what the response covers (scores and status for each simulation type), going beyond the annotation.

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. The first sentence front-loads the core purpose and enumerates result categories; the second provides usage guidance and constraints. Efficient and well-structured.

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

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

For a simple getter with one parameter and an output schema, the description is complete. It covers what the tool returns, how to use it for polling, and the ownership constraint, leaving no significant 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?

With 100% schema coverage, the baseline is 3. The description adds the meaningful constraint 'pass an ideaId you own', which is not present in the schema description. This clarifies the ownership requirement beyond the plain 'The idea ID'.

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 'Return' and the resource 'an overview of every simulation run for an idea', enumerating specific simulation types. It distinguishes itself from sibling run_* tools by focusing on status retrieval, making the tool's role obvious.

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 guides usage: 'Use it to poll async simulations and see what has finished.' This tells the agent when to use the tool after initiating simulations. It does not explicitly mention alternatives or when-not-to-use, but the guidance is clear enough for a polling tool.

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 declare readOnlyHint=true and destructiveHint=false, so the description adds value by stating 'Read-only and free', confirming no mutation or cost. It also adds that you must pass an ideaId you own, which is contextual safety info. 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?

Two sentences: first defines return metrics, second states purpose and access constraints. No extraneous information. Every sentence earns its place.

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

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

Given low complexity (1 param, no nested objects, output schema present), the description is complete. It explains what metrics are returned, the use case, and access condition. Could optionally mention that the output schema includes exactly those four fields, but not required.

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% (ideaId string) so baseline is 3. The description does not add additional parameter details beyond the schema, but it does set context that the ideaId must be owned by the user, which is a nuance not in 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 tool returns social engagement metrics (views, watchlist count, interest signals, share count) for an idea, and explicitly says it gauges traction on the platform. This differentiates it from siblings like get_demand_proof or get_market_signals by focusing specifically on social proof metrics.

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 use for checking traction of an idea, and notes it requires an ideaId you own, but does not explicitly say when not to use it or name alternatives. Sibling tools like get_demand_proof or get_improvement_synthesis could provide similar or complementary data, 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.

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

Annotations already declare readOnlyHint=true, and the description confirms read-only and adds 'free' (no credit cost). It also discloses what data is returned (balance, workflow, tool catalog), going beyond the 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?

Three sentences, zero wasted words. Front-loaded with the purpose and usage directive. Highly efficient.

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

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

The tool is simple (read-only, one optional param, output schema exists). Description covers what it does, when to call, and what it returns. No gaps given the low complexity and rich annotations/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 coverage is 100% and the single parameter (language) has a clear schema with enum and default. The description adds no additional semantic value about the parameter, so 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 is the 'starting point' and 'best first call', and it returns specific artifacts (credit balance, workflow, tool overview). It distinguishes itself from sibling tools by positioning as the first orienting call.

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 advises to call this before anything else. Provides clear context for when to use, but does not explicitly state when not to use or mention alternatives, though the uniqueness is implied.

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 declare readOnlyHint=true and openWorldHint=false. The description adds valuable context beyond annotations: it states the tool is 'Read-only and free' and explains that 'the underlying scan is produced during validation', detailing the data source and cost implications.

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

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

Two sentences: first defines the action and output, second guides usage and adds traits. Every sentence earns its place; 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?

For a simple read-only tool with one parameter and an output schema (present but not shown), the description explains the data origin (validation scan), notes it's free, and summarizes output (scheme names and fit). This, combined with annotations and schema, provides complete guidance.

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 one parameter (ideaId) described. The description does not add meaning beyond the schema (e.g., format, origin of ideaId). Baseline is 3, and no additional value is provided.

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

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

The description explicitly states the verb 'Return' and the resource 'EU subsidy and grant matches', specifying the context (AI-powered EU Subsidy Scanner, for an idea). This clearly distinguishes it from 50+ sibling tools, as no other tool mentions subsidies.

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 directly tells the agent when to use this tool: 'Use this to see which public funding an idea may qualify for.' It does not explicitly state when not to use it or name alternatives, but the unique scope makes exclusion less critical.

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 declare readOnlyHint=true and openWorldHint=false. The description adds value by specifying the exact data sources (playbook, roadmap, first100days) and the merging behavior. It also states 'free', which is not in annotations. 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.

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

Two precise sentences: first states purpose and data origins, second gives usage guidance and sibling reference. No redundant words; information is 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?

Given the presence of an output schema for return values, the description covers all necessary aspects: what the tool retrieves, from which sources, how the source parameter works, and the read-only nature. It integrates well with annotations and schema requirements.

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

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

Schema description coverage is 100% with good base descriptions for ideaId and source. The description adds context about source parameter: 'pick one plan or get all of them merged,' which clarifies how the enum values affect the result beyond the schema's 'Which task source to retrieve'.

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 retrieves structured tasks and milestones for an idea from specified sources (Execution Playbook, Product Roadmap, First 100 Days simulation). It distinguishes itself from the sibling update_task by mentioning 'use update_task to tick First 100 Days items off.'

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 tells when to use this tool (to retrieve tasks) and when not (use update_task for mutating tasks). It also explains the source parameter behavior: 'pick one plan or get all of them merged.' The note 'Read-only and free' assures safe usage.

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 declare readOnlyHint: true, and the description reinforces 'Read-only' without contradiction. Additionally, it adds useful context about being free and requiring membership, which goes beyond the structured fields. No destructive or hidden behaviors are hinted.

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 fluff. The action and purpose are front-loaded, and every word contributes value. It is appropriately sized for a single-parameter tool with annotations and output schema.

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 presence of output schema (documenting return values), annotations (readOnlyHint), and only one required parameter, the description fully covers what an agent needs: purpose, prerequisite, and read-only safety. No gaps remain.

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 'teamId' as 'The team ID'. The description adds meaning by noting that the user must be a member of that team, which provides practical context for parameter usage 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 verb 'Compare' and the resource 'team performance against other teams in the same sector pools'. It differentiates from sibling get_* tools by specifying the context of sector pools and ranking, 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.

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

The description provides explicit context: 'Read-only and free; you must be a member of the team you pass.' It implies when to use (to compare performance) and sets a prerequisite. It does not explicitly list alternatives but is clear enough given the sibling 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?

Annotations already declare readOnlyHint=true, so the description does not need to restate safety. The description adds value by claiming the tool is 'free' (no cost) and explains that the 'days' parameter controls activity history window. It does not contradict annotations. While it could mention pagination or error behavior, the output schema exists to document return details, and the provided context is sufficient for a read-only overview 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 three sentences, each with a distinct purpose: first state the output and components, second give usage guidance, third add behavioral note and parameter hint. No redundant or extraneous information. Key information is front-loaded in the first sentence, making it easy for an agent to quickly grasp the tool's function.

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

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

For a tool with moderate complexity (returning multiple structured components) and an existing output schema, the description covers everything needed: what is returned (members, ideas, credit usage, activity), when to use it (briefing before actions), how to control scope (days parameter), and safety (read-only, free). No critical information is missing for an agent to decide whether to invoke this tool over alternatives.

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%—both parameters have clear descriptions in the input schema. The description adds only a rephrasing for 'days' ('set days to control how much activity history is included'), which is synonymous with the schema. No additional meaning or context is provided for 'teamId'. Thus the description contributes minimal value beyond the schema, justifying the baseline score.

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

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

The description clearly states the tool returns a 'complete overview of a team' listing specific components (members, ideas, credit usage, recent activity). This distinguishes it from numerous sibling get_* tools that are more narrowly focused (e.g., get_achievements, get_team_benchmarks). The explicit verb 'Return' and resource 'overview of a team' make 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.

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

The description gives explicit usage context: 'Use it to brief yourself on a team before acting on its behalf.' This clearly indicates when to invoke the tool. It also notes 'Read-only and free,' implying safe routine use. However, it does not explicitly mention when not to use this tool or suggest alternative sibling tools for more specific needs, leaving room for ambiguity in a large sibling set.

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 provide readOnlyHint=true, so the description's 'Read-only and free' confirms and adds cost semantics. It also describes the return structure (VC score, summary) and chronological ordering, which go beyond annotation fields.

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, front-loaded with purpose, no wasted words. Every sentence earns its place.

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

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

Given the output schema exists (not shown but indicated), the description covers the tool's purpose, usage, parameter, and behavioral traits adequately. It is complete for a read-only tool with one parameter.

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 a basic description ('The idea ID'). The description adds ownership semantics ('pass an ideaId you own'), which is not present in the schema, thus adding meaningful value.

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

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

The description uses a specific verb ('Return') and resource ('the chronological validation snapshots for an idea'), and distinguishes the tool from many sibling get_* tools by focusing on validation snapshots with VC score and summary.

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 states the use case ('compare how validation results changed between runs') and prerequisites ('pass an ideaId you own'). It does not explicitly mention when not to use alternatives, but the context is clear enough.

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 declare readOnlyHint: false, idempotentHint: true, and destructiveHint: false. The description confirms these by stating 'Not read-only; it changes sharing permissions' (consistent) and 'is idempotent, so re-granting the same level is safe' (consistent). It adds value by explaining the idempotent behavior in plain language. No contradiction is present.

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, each serving a clear purpose: stating the action, giving usage context, and noting behavioral traits (read-only status, idempotency). No redundant or 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?

With 3 parameters, a clear description, and an output schema (though not shown), the description covers the core functionality. However, it misses context on potential side effects (e.g., notification sent to the user) or error conditions (e.g., if email does not match a valid user). The 'Not read-only' statement is useful but could be more precise.

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%, and the schema provides clear descriptions for all three parameters. The description adds no further detail on parameter values or format beyond what is already in the schema, which is acceptable per guidelines (baseline 3).

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: 'Grant a team member access to one of your ideas at a chosen access level (view, edit or admin).' It specifies the resource (idea), the recipient (team member by email), and the available access levels. This distinguishes it from siblings like 'create_share_link' (likely a different sharing mechanism) and 'update_idea' (which modifies content, not permissions).

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 says 'Use it to share an idea with a collaborator by email,' providing clear when-to-use guidance. However, it lacks explicit when-not-to-use instructions or alternatives for other sharing methods (e.g., a share link). It also does not clarify prerequisites (e.g., does the target user need an account?).

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 declare readOnlyHint=true, which aligns with 'Read-only' in description. Description adds value by stating 'free' (no cost implications) and 'Admin only' (access control beyond annotations). No contradiction, no behavioral surprises. Minor gap: doesn't disclose if results are paginated or include total counts.

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, 19 words total. Front-loaded with action and resource. Every sentence earns its place: first sentence states capability, second explains utility and constraints. No wasted words.

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

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

Given zero parameters, high schema coverage, output schema exists, and simple list operation, description is largely complete. It explains return content (leads, status), purpose (ID discovery), and constraints (read-only, free, admin). Minor gap: no explicit mention of pagination or result ordering behavior.

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

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

Schema has zero parameters (100% coverage is trivial). Description doesn't need to add param info. It adds meaning about what the list returns ('lead counts and status') and purpose (finding campaign IDs), which is useful semantic context beyond an empty 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 specifies verb 'List', resource 'B2B scouting campaigns', and includes scope details ('with their lead counts and status'). It clearly distinguishes from siblings like 'list_b2b_leads' and 'list_my_ideas' by naming the specific B2B campaign use case.

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 states when to use: 'to find the campaignId values the other B2B tools need', implying it's a prerequisite tool. Also notes 'Read-only and free. Admin only.', covering auth level. No alternative mentioned but context clearly positions it as a discovery tool for downstream B2B operations.

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 provide readOnlyHint=true, so the description's 'Read-only' is redundant. However, it adds valuable behavioral context: 'free' (no cost) and 'Admin only' (role restriction). These go beyond the annotations and help the agent understand constraints.

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

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

The description is extremely concise—four short sentences, each adding distinct value. It is front-loaded with the purpose, then provides usage guidance, then behavioral traits. No wasted words.

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

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

Given the low complexity (2 optional params, output schema present, annotations provided), the description covers all necessary aspects: purpose, usage, constraints (admin only, read-only, free) and key output fields. No obvious 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 100%, so the baseline is 3. The description mentions 'optionally filtered by campaign' but this repeats the schema's campaignId field. No additional parameter semantics (e.g., format, usage tips) are provided 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 tool lists B2B leads with specific fields (business names, opportunity scores, status) and supports optional campaign filtering. This distinguishes it from sibling tools like get_b2b_lead (single lead) and get_b2b_stats (aggregated stats).

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 a clear use case: 'triage which leads to work next.' However, it does not explicitly mention when not to use this tool or offer alternatives. The context is well-defined but lacks exclusionary 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 annotations already include readOnlyHint=true, making the read-only nature clear. The description adds 'free' (no cost) and mentions the ordering (newest first) and optional search term, which are behavioral details beyond the annotations. No contradiction is present.

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 wasted words. Every sentence adds value: first sentence describes what the tool does, second sentence tells when to use it and mentions the search filter. Highly efficient.

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

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

Given the tool is a simple list with an output schema, two parameters, and clear annotations, the description is completely adequate. It covers purpose, usage, behavioral aspects, and parameter hinting, leaving no gaps for an AI agent to misunderstand.

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 input schema already documents both parameters (limit and search) with descriptions. The description adds no additional parameter semantics beyond what the schema provides, thus the baseline score of 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 explicitly states the tool lists ideas owned by the user, including specific fields (title, VC score, creation date) and ordering (newest first). This clearly distinguishes it from siblings like search_ideas (which searches broadly) and get_portfolio (which likely has a different view).

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 explains exactly when to use this tool: to discover ideaId values for other tools or to get a quick portfolio snapshot. It explicitly states it is read-only and free, and mentions the optional search parameter for narrowing results, providing clear usage context.

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 declare readOnlyHint=true. The description adds value by confirming 'Read-only and free' and specifying the data scope ('your own memberships') and return content (role, basic stats, teamId). 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.

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

Three succinct sentences, front-loaded with purpose. Every sentence adds essential information: purpose, usage, and behavioral traits. No wasted words.

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

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

The description covers purpose, scope, return content, and use case. It does not mention pagination or limits, but for a tool returning all own teams with no parameters, this is likely complete. The presence of an output schema further reduces required detail.

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 zero parameters and 100% schema coverage, the baseline is 4. The description correctly states 'takes no parameters' and adds the implicit filtering to own memberships, which is sufficient meaning.

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 lists every team the user belongs to, with role and basic stats. It specifies the purpose of finding teamId for other team tools, distinguishing it from siblings that require a teamId as input.

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 to use it to find teamId values needed by other team tools, providing clear context. No when-not-to-use guidance is necessary given its simple, prerequisite nature.

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 declare readOnlyHint=true. The description adds 'Read-only and free; you must be a member of the team', which reinforces the safety profile and adds cost context and membership requirement. 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.

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

Two sentences, front-loaded with the core purpose. Every word earns its place: purpose, ordering, optional search, usage context, prerequisite, membership, and read-only/free status. 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 the tool's simplicity (3 parameters, output schema present, read-only, no nested objects), the description fully covers purpose, usage, ordering, prerequisite, membership, and optional search. Nothing essential is missing.

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% (all three parameters have descriptions in the schema). The description adds no additional parameter semantics beyond what the schema provides, except implicitly mentioning 'newest first' ordering which is not a parameter. 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 verb 'list', the resource 'ideas', the scope 'belong to a team', ordering 'newest first', and optional keyword search. It distinguishes from siblings like list_my_ideas and search_ideas by specifying team membership and a prior step to get teamId.

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 says 'use it to review a team portfolio once you have a teamId from list_my_teams', providing a clear prerequisite and usage scenario. It implies membership requirement but does not explicitly contrast with other list tools (e.g., list_my_ideas), missing a small opportunity for 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?

The description explicitly states it is 'not read-only' and 'not idempotent', and that 'each call appends a new event'. This aligns with annotations (readOnlyHint: false, idempotentHint: false) and adds behavioral context beyond the annotations, such as the non-idempotent appending behavior. There is 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.

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

The description is three sentences, clearly front-loaded with the primary purpose. The first sentence immediately states what the tool does and its context, followed by a list of events and a warning about behavior. Every sentence is essential and adds value, with no 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 has 7 parameters (2 required), an output schema (not shown but indicated), and annotations covering read-only and idempotence, the description is reasonably complete. It explains the tool's effect on the idea's timeline, lists events, and warns about non-idempotence. A minor gap is not specifying how the event affects the timeline or what the response looks like, but the presence of an output schema likely addresses return values.

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

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

The input schema provides full (100%) descriptions for all 7 parameters, so the baseline is 3. The description adds value by listing all valid event values inline (though also present in the schema), and by framing the purpose of the parameters ('log a build event', 'keep timeline up to date'). However, it does not explain the 'message' or 'metadata' parameters beyond what the schema provides.

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

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

The description clearly states the verb ('Log') and the resource ('build event for an idea'), and explains the purpose ('keep its build timeline up to date'). It lists valid event types, which helps the agent understand the scope. This differentiates it from siblings like 'update_idea' or 'update_idea_status' which focus on different aspects.

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 states it is 'not read-only' and 'not idempotent', which guides against misuse. It does not provide explicit when-not-to-use guidance or mention alternative tools among the many siblings, but the context of appending events to a timeline is clear and sufficient for most use cases.

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 useful behavioral context beyond the readOnlyHint annotation, including the 1-credit cost, the use of maxBudget as a cap on suggestion claim cost, and the inputs drawn from Founder DNA, existing ideas, and preferences. It doesn't contradict annotations and gives operational detail.

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: three short sentences that lead with the action, then usage context, then cost/budget guidance. Every sentence earns its place and important constraints are 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?

With the annotations, full schema descriptions, and output schema present, this description completes the picture by adding cost, personalization source, and affordability filtering behavior. The agent has enough to decide when to invoke and how to configured parameters.

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 already provides 100% coverage for all three parameters, with clear descriptions for language, maxBudget, and preferences. The tool description recontextualizes maxBudget as a cap on claim cost, but adds little beyond what the input schema provides.

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

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

The description states a specific action: 'get personalised, ranked idea recommendations drawn from your Founder DNA, existing ideas and stated preferences', clearly explaining what it returns and its personalization inputs. It distinguishes itself from siblings like search_ideas or get_pivot_suggestions by emphasizing ranking, claimable ideas, and affordability filtering.

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 says when to use the tool: 'Use it when you want the platform to surface the best-fitting claimable ideas for you.' It does not explicitly mention alternative tools or when-not-to-use, but the context is clear enough within the sibling set.

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 set readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds critical behavioral context beyond these annotations: 'This spends credits and starts background work; not read-only.' This informs the agent of non-idempotent, credit-costly, asynchronous behavior that the annotations alone do not fully convey. 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.

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

Three sentences, each earning its place: the first states the core purpose and trigger, the second provides an optional usage variant, and the third covers critical behavioral side effects. No wasted words.

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

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

Given the tool has only 3 parameters (all documented in schema), has a high schema coverage, and has no nested objects, the description is complete. It covers the trigger, optional parameter usage, and side effects (credit cost, background work, non-read-only). With an output schema present, the description does not need to detail return values.

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 is 3. The description adds value by clarifying the meaning of the 'agents' parameter ('Optionally target specific agents instead of the full suite'), but the 'ideaId' and 'reason' parameters are adequately described in the schema. The description does not add significant new semantics beyond the schema, so 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 requests a 'fresh validation run for an idea after a significant pivot or update', specifying the verb ('request'), resource ('validation run'), and context ('after a pivot or update'). It also distinguishes itself from the sibling 'validate_my_idea' by mentioning an optionally targeted set of agents and the production of a 'VC score', which is unique among siblings.

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 states when to use this tool ('after a significant pivot or update') and what it does ('re-running the AI agents'). It also provides an important usage alternative: 'Optionally target specific agents instead of the full suite.' Behavioral cautions ('spends credits and starts background work; not read-only') further guide appropriate 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?

The description adds significant behavioral detail beyond the annotations: it clarifies that the tool spends credits, runs as an async job, and returns a session ID for polling. This goes beyond the readOnlyHint=false annotation and provides crucial transparency about side effects and workflow, with 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.

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

The description is extremely concise: two sentences totaling about 30 words. The first sentence fronts the core purpose and return value; the second adds critical usage notes. Every sentence serves a clear purpose with no 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 that the tool has an output schema and annotations, the description covers the main behavioral aspects: async polling, credit cost, and required parameters. It does not detail error cases or the polling endpoint, but the presence of an output schema likely covers return structure, making this fairly complete for an agent.

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

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

All three parameters are described in the schema with 100% coverage, earning a baseline of 3. The tool description merely echoes the parameter names (ideaId, opponentIdeaId) without adding new semantic value, such as format constraints or usage tips for the optional language 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: starting an Arena Duel that compares two ideas using AI, returning a session ID. It uses specific verbs (start, pits) and resources (arena duel, idea, competitor idea), effectively distinguishing it from sibling tools like run_survival_mode or run_time_machine.

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

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

The description provides explicit usage context: it spends credits, is asynchronous, requires checking credits first, and is not read-only. However, it does not explicitly state when not to use it or mention alternative tools, so it is slightly lacking in 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?

Beyond annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description adds critical context: the tool costs tokens, is not read-only, and requires admin privileges. This transparency about cost and authorization goes well beyond structured fields, with no contradictions to annotations.

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

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

The description is two sentences, front-loaded with the core purpose ('Run an AI diagnosis on a B2B lead: digital maturity, opportunities and a recommended approach') followed by essential behavioral notes. Every sentence earns its place with zero 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?

With one simple parameter, high schema coverage, an existing output schema, and annotations, the description fully covers what an agent needs: purpose, output scope, cost implications, and authorization requirements. No gaps remain for this tool's complexity level.

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 leadId described as 'The lead ID to diagnose'. The tool description does not add new parameter-level details beyond what the schema provides, so it meets the baseline of 3 without further enrichment.

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 runs an AI diagnosis on a B2B lead, covering digital maturity, opportunities, and a recommended approach. It distinguishes itself from sibling tools like get_b2b_lead (retrieves lead data) and generate_b2b_pitch (generates a pitch) by specifying the action 'run' and the resource 'diagnosis'.

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 that the tool calls the LLM, costs tokens, is not read-only, and is admin-only, which provides clear context for when to use it. However, it does not explicitly list when not to use it or compare to alternative siblings like get_b2b_lead for simple data retrieval, leaving some ambiguity.

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 set readOnlyHint=false and destructiveHint=false, so the description adds vital context: it spends credits, starts a background job, and returns a session ID for an async result. This goes well beyond annotations by explaining the non-read-only, non-idempotent nature of credit consumption and async processing. 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 two concise sentences, front-loading the core purpose and then adding key behavioral notes. Every sentence provides essential information—what the tool does, async nature, credit cost, and parameter guidance. No wasted words.

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

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

Given the existing output schema and 100% parameter coverage, the description covers the key points: purpose, async return, credit cost, ownership requirement, and optional persona. It could mention the expected runtime or how to retrieve results (e.g., using session ID) for full completeness, but it is adequate 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.

Does 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 that personaType is optional (defaults auto-selected) and ties language to response language. It doesn't elaborate on ideaId beyond stating ownership requirement, but the schema already describes it as 'the idea ID'. The added context about ownership and optional persona is helpful but not extensive.

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 'Run a Customer Discovery session: synthetic interviews with AI-generated customer personas who react to your idea', using specific verbs and resources. It distinguishes from siblings like 'run_b2b_diagnosis', 'run_arena_duel', 'run_survival_mode', and 'run_time_machine' by explaining it involves customer discovery interviews with personas, which is unique.

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 'This spends credits and starts a background job', setting expectations about cost and async behavior. It also mentions 'pass an ideaId you own and optionally target a specific persona type', giving clear input requirements. However, it does not explicitly state when not to use this tool or name alternative tools for context.

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