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

Discloses that the tool modifies the real profile and mentions the Freelancer-imposed maximum skills limit. Annotations (idempotentHint=true) are not contradicted; the description adds useful behavioral context beyond 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?

Efficiently structured with clear sections (Args, Returns, warning, usage). Every sentence adds value, no fluff. Properly front-loaded with the main 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 complexity (profile modification, multiple accounts) and absence of output schema, the description covers all essential aspects: functionality, parameters, warnings, and usage clues. It also differentiates from sibling tools adequately.

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?

Adds meaningful details beyond the schema: explains that skills can be names or numeric IDs, names are resolved via the catalogue, and account is optional with a reference to freelancer_list_accounts. Schema coverage is 100%, but the description enriches understanding.

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

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

Clearly states it adds skills to Freelancer.com profile while preserving existing ones. Differentiated from siblings like freelancer_set_skills and freelancer_remove_skills by explicitly mentioning 'keeping your existing skills'.

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

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

Provides explicit use examples for the agent (e.g., 'Add n8n and Zapier to my skills'). Implicitly contrasts with freelancer_set_skills by noting skills are added, not replaced. Could explicitly state when not to use it, but the examples and sibling list make it 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?

Annotations are present. The description adds valuable behavioral context: it warns about real data creation, caps on specialty profiles, and possible rejection for certain account types. 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 mostly concise, with a clear opening sentence and separate sections for arguments, warnings, and usage. The argument list somewhat duplicates schema but is acceptable.

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

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

Given no output schema, the description explains the return value. It covers important edge cases (caps, account types) and provides sufficient context for an AI agent to 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%, so baseline 3. However, the description claims 'All fields are required by the API' while the schema lists two optional fields (skills, account). This misleads the AI agent and reduces trust.

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 it creates a new specialty profile, distinguishes it from the main account profile, and contrasts with siblings like freelancer_update_profile and freelancer_list_profiles.

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 includes a 'Use when' example but does not explicitly state when not to use it or provide comparisons to alternatives. It mentions account type restrictions, but the guidance is minimal.

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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying the return format (messages with text, sender, timestamp, attachment info) and that thread_id can accept a link. This enriches behavioral understanding without contradicting 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 well-organized into sections (Args, Returns, Use when) and is free of redundancy. Every sentence serves a purpose, making it easy for the agent to parse quickly.

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 4 parameters, high schema coverage, and presence of annotations, the description thoroughly covers the tool's behavior: parameter details, return structure, usage examples, and guidance on sibling tools. No critical information is missing for correct agent usage.

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%, but the description adds extra meaning: for thread_id it mentions accepting a chat link, for limit it restates the range and default, and for account it references freelancer_list_accounts for labels. This goes beyond the schema's descriptions.

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 messages from a specific Freelancer.com thread, with concrete usage examples ('Show messages in thread 12345'). It distinguishes from siblings like freelancer_list_threads (listing threads) and freelancer_send_message (sending messages).

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?

Explicit 'Use when' examples are provided, and it tells the agent to use freelancer_list_threads if the thread_id is unknown. This gives clear context for when to invoke this tool versus alternatives.

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, idempotentHint, and destructiveHint, so the description's safety profile is well-covered. The description adds return format and statuses, which is useful but does not disclose additional behavioral details like pagination or auth requirements.

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 well-structured with clear sections (Args, Returns, Statuses, Use when) but is slightly verbose due to repeating parameter descriptions. Nonetheless, every sentence 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?

For a read-only list tool with no output schema, the description adequately explains return fields and statuses. Parameters are fully documented. Minor missing details (e.g., ordering, pagination) 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 description coverage is 100%, so baseline is 3. The description repeats the same parameter descriptions as the schema, with no extra semantic clarity beyond what the schema 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 lists milestones for a Freelancer.com project, with a specific verb ('list') and resource ('milestones'). It distinguishes from sibling tools like 'freelancer_get_project' or 'freelancer_get_project_bids' by focusing on 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 provides explicit examples of when to use (e.g., 'What are the milestones on project 12345?', 'Has the milestone been released?'). It lacks explicit when-not-to-use or alternative tools, but the context is clear.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by specifying the returned fields (description, budget, status, etc.), providing 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 concise with no wasted words; it front-loads the purpose and efficiently covers parameters, return content, and usage examples.

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 get-by-id tool with 2 parameters and no output schema, the description covers purpose, parameters, return content, and usage examples. It omits error handling but is otherwise 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%, and the description's 'Args' section mostly mirrors the schema descriptions. However, it adds a small extra by referencing freelancer_list_accounts for account labels.

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 'Get full details of a specific Freelancer.com project by ID', using a specific verb and resource, and it distinguishes from sibling tools like get_messages or search_projects by focusing on project details retrieval.

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 provides explicit usage examples like 'Tell me more about project 12345678' and explains when to use it, but does not explicitly state when not to use it or compare to alternatives such as freelancer_search_projects.

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 idempotentHint=true. The description adds value by specifying return fields (amount, period, bidder reputation, description). 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 concise with an Args list, return statement, and use-case examples. Every sentence is informative 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?

Though no output schema is provided, the description lists key return fields. Parameter documentation is complete with ranges and defaults. The tool is simple and the description covers all needed 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?

Schema coverage is 100%, so the description adds minimal new meaning beyond restating parameters. It reiterates the account usage hint already present 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 'List all bids on a specific Freelancer.com project' using a specific verb and resource. It distinguishes itself from sibling tools like freelancer_my_bids (user's own bids) and freelancer_place_bid.

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 example queries ('Who has bid on project 12345?') and notes optional account usage. However, it does not mention when not to use this tool or alternatives for cross-project bids.

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 indicate readOnlyHint, idempotentHint, destructiveHint=false. Description adds detail on what fields are returned (reputation, earnings, etc.), exceeding the minimal annotation coverage.

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?

Description is front-loaded with the main purpose and includes a useful Returns section. The Args block is somewhat redundant with the schema, but overall it remains concise and well-organized.

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?

Despite no output schema, the description thoroughly explains return values (username, location, etc.) and provides usage examples. It is fully adequate for a simple read-only tool with good annotations.

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

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

Schema coverage is 100% for the single optional parameter. The description's Args block mostly duplicates the schema, adding no new semantic value beyond what is already documented.

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

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

Clearly states 'Retrieve your own Freelancer.com profile' with specific verb and resource. Distinguishes from sibling tools like freelancer_get_user (other user) and freelancer_update_profile (modify).

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

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

Provides explicit usage examples like 'What's my profile?' in the 'Use when' section, giving clear context. However, it does not explicitly state when not to use or mention alternatives.

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, openWorldHint, idempotentHint, and destructiveHint, covering most behavioral aspects. The description adds value by listing the return fields (profile, reputation, skills, location, hourly rate), which is not in the 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?

The description is highly concise with one main sentence, bullet-style args, a 'Returns' list, and a 'Use when' section. Every sentence is informative, and no waste is present.

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 and the lack of an output schema, the description covers the return fields and parameters completely. It could mention potential error cases or rate limits, but for a read-only, idempotent retrieval tool, this is sufficient.

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

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

With 100% schema coverage, the baseline is 3. The description adds meaning by explaining the account parameter (referring to freelancer_list_accounts), noting that at least one of username or user_id is required, and providing an example username. This goes 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 'Retrieve a Freelancer.com user profile by username or user ID,' with a specific verb, resource, and method. It distinguishes from sibling tools like freelancer_get_self (own profile) and freelancer_list_profiles (list of profiles).

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 instructions: the optional parameters, the requirement to provide at least one of username or user_id, and a 'Use when' section with example queries. It does not explicitly state when not to use it or list alternatives, but the context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavior: it does not return tokens, and it identifies the default account. This context supplements 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, using bullet-like paragraphs. Every sentence adds value: purpose, security note, return info, usage examples. 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?

For a tool with no parameters and a clear output, the description covers all necessary aspects: purpose, usage guidance, return content, and integration with other tools. Output schema is not needed due to explanatory text.

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 description explains the output (account labels, default account) and purpose, fully leveraging the absence of input complexity.

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 Freelancer.com account labels, a distinct resource from sibling tools like freelancer_list_profiles or freelancer_get_self. It specifies 'never the tokens themselves', adding precision.

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: to discover which account value to pass to other tools when multiple profiles are connected. Example queries like 'Which Freelancer accounts are connected?' provide clear invocation 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?

Annotations already indicate read-only and idempotent behavior. Description adds important context about API limitation and return fields (name, tagline, hourly rate, description). Could potentially mention error handling for invalid IDs, but not critical.

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

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

Extremely concise and well-structured with clear sections (Note, Args, Returns, Use when). Every sentence adds value without redundancy.

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

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

For a simple read tool with two parameters, the description covers purpose, parameters, return format, and usage constraints. Lacks error handling details, but that is acceptable given annotations.

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

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

Schema has 100% description coverage, so baseline is 3. The description adds the note about needing to know IDs, which aids understanding but parameter descriptions are nearly identical to schema. Minor added 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?

Description clearly states the tool fetches specialty profiles by numeric IDs. Title 'List Specialty Profiles' aligns with action. Sibling tools like freelancer_create_profile or freelancer_update_profile are distinct in 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?

Explicit 'Use when' example provided. Notes that profile IDs must be known upfront due to API limitation, preventing misuse. Also explains optional account parameter referencing freelancer_list_accounts.

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, idempotentHint=true, and destructiveHint=false, so the description adds value by specifying the return structure (numeric ID, name, category). No contradictions exist, and the behavior is well-disclosed.

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—four lines covering purpose, return fields, arguments, and usage examples—with no unnecessary words. Information is front-loaded 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?

Despite no output schema, the description explicitly states what is returned (ID, name, category), which is sufficient for a list tool. The sole optional parameter is fully documented, and the use-case examples complete the contextual picture.

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 the single optional parameter 'account', and the description repeats the schema's explanation about using freelancer_list_accounts for labels. While the cross-reference is helpful, the description doesn't add significant new meaning beyond the schema, so a 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 title 'List My Skills' and description 'List the skills (jobs) currently on your own Freelancer.com profile' use a specific verb (list) and resource (skills on own profile), clearly distinguishing it from sibling tools like freelancer_search_skills (search all skills) and freelancer_set_skills (modify).

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 'Use when:' section provides concrete example queries, giving clear context for when to invoke the tool. It also cross-references freelancer_list_accounts for the account parameter. While it doesn't explicitly state when not to use or list alternative tools, the examples are sufficient for typical 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description does not need to reiterate that. It adds value by describing the return structure ('list of threads with members, last activity and message count') and the optional context_type filter, which are beyond what annotations provide.

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: a single opening sentence, a structured arg list, a return description, and usage examples. Every sentence 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's complexity (no required params, simple parameters, read-only, idempotent), the description fully covers what the agent needs: purpose, parameters (with defaults and constraints), return structure, and example triggers. 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 description coverage is 100%, providing baseline clarity. The description adds context for the account parameter (e.g., linking to freelancer_list_accounts) and clarifies default behavior for limit and offset. This extra guidance slightly improves semantics 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 'List' and the resource 'Freelancer.com inbox message threads,' making the tool's purpose unambiguous. It distinguishes itself from sibling tools like freelancer_get_messages (which retrieves messages within a thread) and freelancer_send_message.

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?

Usage examples are provided (e.g., 'Show my inbox', 'List my message threads'), giving clear context for when to use the tool. However, it does not explicitly exclude cases where alternatives like freelancer_get_messages would be more appropriate.

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, destructiveHint=false, idempotentHint=true. The description adds that it returns bids with project info, amounts, and status, and suggests a specific analysis pattern. 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 well-structured with clear sections: purpose, arguments, returns, and usage examples. It is slightly long but every sentence adds value, and the front-loading is effective.

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 read-only list tool with 4 optional parameters and no output schema, the description sufficiently explains the return type ('your bids with project info, amounts and status') and provides a usage pattern. It meets the needs for an AI agent to 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%, so the baseline is 3. The description adds value by explaining the 'account' parameter refers to another tool, and provides an example usage for status-based analysis. This goes 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 it lists bids placed by the user. It distinguishes from siblings like 'freelancer_get_project_bids' (bids on a specific project) and 'freelancer_my_projects' (user's projects), making the tool's purpose unambiguous.

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

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

Explicit use cases are provided: 'Show my bids', 'Which of my bids are active?', 'Have any of my bids been awarded?', 'What's my win rate?', and an analysis strategy. However, it could mention when to use alternative tools like 'freelancer_get_project_bids' for a specific project's bids.

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 indicate readOnly, destructiveHint false, idempotent. The description adds that it returns a list with status, budget, and progress, and explains pagination via offset/limit. It doesn't discuss rate limits or data freshness, but the extra context is valuable.

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 well-organized: a one-sentence summary, then args in clear bullet-like format, then returns, then use-case. It is not overly verbose, though the return description could be slightly more concise. Still, every sentence 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 no output schema, the description adequately covers return value structure (list with status, budget, progress). It also explains pagination and provides a sophisticated multi-tool usage scenario. For a list tool with good annotations, 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%, but the description adds value by explaining defaults (e.g., role default 'freelancer'), clarifying the account parameter's reference to another tool, and providing human-readable explanations for enums. This goes beyond the schema's brief field descriptions.

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 projects the user owns or is hired on. It distinguishes from siblings like 'freelancer_search_projects' which searches all projects, and 'freelancer_my_bids' which lists bids. The verb 'list' combined with 'your projects' specifies the resource and scope.

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 examples ('Show my active projects', etc.) and includes guidance on when to use it for analysis, pairing with 'freelancer_my_bids'. It tells the agent to reason over combined results, which is a clear usage scenario.

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

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

The description warns that this creates a real bid, advising review before confirming, and clarifies the role of the account parameter. This adds significant behavioral context beyond the annotations, which only show non-read-only and non-destructive hints.

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 well-structured with an Args block, warning, and usage examples. While relatively long, each section serves a purpose and adds value, making it efficiently informative.

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 with 6 parameters and no output schema, the description covers all parameters, specifies return values (confirmation with bid ID and status), and includes a critical warning about real-world consequences.

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%, but the description adds meaningful context, such as 'milestone_percentage default 100' and that account specifies which account the bid is placed FROM. This clarifies usage beyond the schema's base descriptions.

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 'Submit a bid / proposal on a Freelancer.com project,' using a specific verb and resource. It distinguishes itself from sibling tools like freelancer_get_project_bids (which only reads bids) by emphasizing the act of placing a bid.

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 includes example queries like 'Bid $150 on project 12345 with 7 days delivery,' indicating when to use it. It also refers to freelancer_list_accounts for account selection but does not explicitly exclude scenarios where other tools should be used.

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, it warns '⚠️ This modifies your real profile.' and mentions return value as confirmation. Annotations already indicate destructive and idempotent hints, so description adds useful 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?

Well-structured with clear sections: purpose, args, returns, warning, and usage examples. Every sentence serves a purpose, 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?

Covers essential aspects: what it does, parameters, warning about modification, return value, and usage examples. No output schema needed as return is simple confirmation.

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. Description explains the skills parameter can be names or numeric IDs (already in schema) and clarifies the account parameter references freelancer_list_accounts, adding 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?

Clearly states the verb 'remove' and the resource 'skills from your Freelancer.com profile'. Distinguishes from sibling tools like freelancer_add_skills and freelancer_set_skills.

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

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

Provides explicit 'Use when:' examples, but does not differentiate from alternatives like adding or setting skills. Nonetheless, the examples are helpful for typical 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?

Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds that results are 'ordered newest-first,' which is valuable behavioral context beyond 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?

The description is well-structured with a clear purpose, args list, returns section, and use cases. It is concise, though some repetition exists (e.g., 'Number of results' in both description and schema). Overall, every sentence serves a 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?

Considering the 7 optional parameters, full annotations, and no output schema, the description adequately explains return fields (title, budget, bid count, skills) and ordering. It lacks error handling or pagination details, but these are covered by parameters. It is complete enough for typical use.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by providing example keywords for the 'query' parameter, detailing budget descriptions ('in USD'), and including cross-tool guidance for the 'account' parameter (reference to freelancer_list_accounts).

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 'Search for projects/jobs on Freelancer.com by keyword, budget or project type,' which clearly defines the tool's action (search) and resource (projects). It distinguishes itself from siblings like freelancer_get_project (specific project) and freelancer_my_projects (user's own projects) by focusing on public search.

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 example queries and use cases, such as 'Find projects for Zoho CRM' and 'Show me hourly WordPress jobs,' which guide when to use the tool. However, it does not explicitly mention when not to use it or how it differs from similar search tools like freelancer_search_skills.

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 indicate readOnlyHint=true and idempotentHint=true. The description adds value by detailing case-insensitive substring search, return format (ID, name, category), and the purpose of finding IDs for management tools. 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 well-structured: purpose sentence, Args section, Returns, Use when with examples. Every sentence is informative, front-loaded, and no wasted words. Examples enhance clarity without verbosity.

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, no output schema, and that annotations cover safety, the description fully addresses what the tool does, what parameters mean, what is returned, and when to use it. 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?

Schema coverage is 100%, so baseline is 3. The description adds value through concrete examples for 'query' (e.g., 'python', 'n8n', 'automation') and mentions default limit, providing practical usage context beyond schema descriptions.

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 'search', the resource 'Freelancer.com skill catalogue', and the purpose: find numeric skill IDs for other tools. It distinguishes from sibling tools like freelancer_list_skills and freelancer_set_skills.

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 includes an explicit 'Use when' section with example queries, providing clear context for when to invoke the tool. It lacks explicit exclusion guidance but effectively implies usage 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 includes a warning: '⚠️ This sends a real message from your account.' Annotations indicate readOnlyHint=false, and the warning adds behavioral context beyond the annotations, clarifying the real-world impact.

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 and well-structured, with the purpose front-loaded. The Args section is clear, though it slightly duplicates the schema. The warning is effectively placed.

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 adequately covers input and behavior for a simple send action. It mentions return is 'confirmation with message ID', but without an output schema, more detail about the confirmation structure would be beneficial.

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% (baseline 3). The description adds value by explaining that thread_id can be a Freelancer chat link, and that account 'is the account the message is sent FROM', which goes beyond the schema's description.

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

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

The description clearly states 'Send a message in an existing Freelancer.com thread' and provides example use cases like 'Reply to thread 12345 saying...'. It distinguishes from siblings such as freelancer_get_messages and freelancer_list_threads.

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 'Use when:' examples and explains the optional account parameter with reference to freelancer_list_accounts. It doesn't explicitly state when not to use, but the examples and context make it 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?

Description reinforces annotations (destructiveHint=true) by stating 'Destructive: this overwrites all existing skills' and 'Any current skill not in the list is removed.' Adds context about account parameter usage and correct return 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?

Description is well-structured: core purpose first, then Args section, Returns, warning, and usage examples. Every sentence adds value without redundancy.

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

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

No output schema, but 'Returns: confirmation' is sufficient for a mutation tool. With detailed annotations, clear parameter descriptions, and alternative suggestions, the description is fully 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?

Schema coverage is 100%, but description adds meaning: skills are 'complete set of skill names or numeric IDs' and account parameter clarifies 'see freelancer_list_accounts for labels'. This aids agent understanding beyond 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 title 'Set Skills (Replace All)' and description 'Replace your ENTIRE skill list' clearly state the verb (replace) and resource (skill list). It distinguishes from siblings like freelancer_add_skills (append) and freelancer_remove_skills (remove specific).

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 suggests 'Consider freelancer_list_skills first, and freelancer_add_skills if you only want to append.' Also provides example use cases ('Set my skills to exactly Python, n8n and React', 'Replace all my skills with this list') and warns about destructive 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 indicate the tool is non-read-only, idempotent, and non-destructive. The description adds that it modifies real data, the API enforces ownership, and only supplied fields are changed. This provides additional behavioral context beyond 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 well-structured with a clear statement, an important note, a parameter list, behavioral notes, and a usage example. Each part contributes value, though it could be slightly more concise.

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

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

Given the tool has 6 parameters and no output schema, the description covers the use case, prerequisites, ownership enforcement, and partial update behavior. It lacks details on error handling or synchronous/asynchronous behavior, but is largely complete for a mutation 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%, but the description adds extra meaning: hourly_rate is in USD, skills replaces the profile's skills, and account refers to freelancer_list_accounts. This goes beyond the schema descriptions, making parameters clearer for the agent.

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 updates fields on a specialty profile and explicitly distinguishes it from the main account profile, which is web-UI-only. It specifies the resource (specialty profile) and the action (update), and differentiates from sibling tools like freelancer_create_profile.

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 usage example ('Use when: Update specialty profile 12345's hourly rate to 40'), states the prerequisite of knowing the profile_id, and explains that the account parameter can be omitted. It notes that this tool does not edit the main profile, but does not explicitly mention alternatives for skills management or other profile operations.

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