Server Quality Checklist

Tool Scores

• test_foxbrizrioC
  2.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description fully carries the burden of behavioral disclosure. However, it does not disclose whether this tool has side effects (like creating a test record), whether it requires authentication, or what happens in error cases. For a test tool, it would be valuable to know if it's read-only or has any state-changing impact.

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

  Conciseness4/5

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

  The description is a single, concise sentence that efficiently conveys the tool's purpose. It is front-loaded with 'Herramienta de prueba' (test tool) and is appropriately short for a utility like a health-check endpoint. No wasted words.

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

  Completeness2/5

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

  Given the tool's simplicity (1 parameter, no output schema, no nested objects) and the sibling context, the description is incomplete. It does not clarify what happens when the tool is invoked successfully (e.g., returns a confirmation message?), what types of test messages are expected, or how it integrates with the video generation workflow implied by sibling tools.

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

  Parameters3/5

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

  With only 1 parameter and 100% schema description coverage, the schema already documents what 'message' is (a test message). The description adds no additional meaning beyond 'Mensaje de prueba'. The baseline is 3 as schema covers it fully, and the description doesn't degrade.

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

  Purpose3/5

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

  The description states this is a test tool for verifying Foxbrizrio MCP works. It clearly indicates this is a health-check or validation tool, but it doesn't specify what exactly will be tested (connectivity? auth? system availability?) or what constitutes success/failure. Compared to sibling tools like 'generate_foxbrizio_script' or 'download_completed_video', its purpose is reasonably distinct as a test tool.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool vs alternatives. The sibling tools include 'select_foxbrizio_presenter', 'search_fabrizio_tweets', and various generation tools, but there is no indication of whether this test should be run before or after other operations, or if it's a prerequisite. The description simply states it's a test tool without usage context.

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

• generate_foxbrizio_audioC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden for behavioral disclosure. The description only says it generates audio, implying a non-destructive operation, but does not disclose potential side effects, permission requirements, rate limits, or whether it invokes an external API. This is a significant gap for a tool that likely makes network calls to ElevenLabs.

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

  Conciseness4/5

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

  The single-sentence description is concise and front-loaded with the main purpose. It could be improved by including a brief usage hint or behavioral note without becoming verbose. No redundancy or filler.

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

  Completeness2/5

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

  Given the tool has 5 parameters (including voice, speed, stability) and no output schema, the description is incomplete. It does not explain the return format (e.g., file path, URL, or base64 audio), any processing time expectations, or failure modes. The complexity of ElevenLabs integration is not addressed.

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

  Parameters3/5

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

  The input schema has 100% description coverage for all 5 parameters, so the baseline is 3. The description adds no additional semantic meaning beyond what the schema already provides. It does not clarify default behavior, the relationship between voice_id and voice_name, or offer usage tips. The schema descriptions are adequate but the tool description adds nothing new.

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

  Purpose4/5

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

  The description clearly states it generates audio for Foxbrizio Romano using ElevenLabs with a provided script. The verb 'genera' and the specific resource 'audio de Foxbrizio Romano' are present. It differentiates from siblings like 'generate_foxbrizio_script' (which makes the script, not the audio) and 'generate_complete_foxbrizio_video' (which likely combines audio and video). However, it does not explicitly contrast with these siblings to earn a 5.

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

  Usage Guidelines2/5

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

  The description lacks guidance on when to use this tool versus alternatives. It does not mention necessary prerequisites (e.g., needing a script from generate_foxbrizio_script first) or scenarios to avoid. There is no mention of alternatives or exclusions.

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

• generate_foxbrizio_captionC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It only states the function (generating a caption) with vague optimization claims ('viral', 'engagement máximo'). It does not disclose whether the tool is read-only, any side effects, required permissions, or what the output format looks like.

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

  Conciseness4/5

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

  The description is a single sentence, front-loaded with the key action. It is concise with no wasted words. However, it could be slightly more informative without losing brevity, e.g., by mentioning the input-output relationship.

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

  Completeness2/5

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

  Given the tool has 4 parameters, no output schema, and no annotations, the description is too minimal. It lacks context about the generation process, the relationship between script and caption, and how platform-specific optimization works. The sibling tools suggest a pipeline, but this description does not clarify its place in it.

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

  Parameters3/5

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

  Schema description coverage is 100% with all parameters documented inline. The tool description adds no additional meaning beyond the schema. Per guidelines, baseline is 3 for high coverage, and the description does not improve or degrade this.

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

  Purpose4/5

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

  The description clearly states the tool generates a viral caption for social networks optimized for engagement. The verb 'genera' and resource 'caption' are specific. However, it does not differentiate from sibling tools like generate_foxbrizio_script, which also generates content for the same domain.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context that would help an agent decide between this and generate_foxbrizio_script or other siblings.

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

• scrape_fabrizio_tweetsC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions 'optimizado' but discloses no behavioral traits like rate limits, authentication needs, data mutability, or termination behavior. Critical gaps for a scraping tool.

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

  Conciseness4/5

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

  A single, efficient sentence with no extraneous words. Though in Spanish, it is front-loaded with the core action. Could be improved with a brief structuring of actions.

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

  Completeness2/5

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

  Given the complexity (multiple actions, no output schema, scraping scope), the description is insufficient. It does not explain the difference between scrape, recent, and vip actions, nor what data is returned. Important context is missing.

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

  Parameters3/5

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

  Schema coverage is 100%, so each parameter already has a description. The tool description adds no additional meaning about how count, hours, action, or save_to_database behave or interact. Baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states it scrapes tweets of Fabrizio Romano using TwitterAPI.io optimized, identifying the verb, resource, and method. However, it does not explicitly distinguish itself from the sibling 'search_fabrizio_tweets', though the action parameter adds nuance.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like search_fabrizio_tweets or test_foxbrizrio. It lacks when-to-use, when-not-to-use, or alternative references.

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

• start_video_generationB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It only mentions 'sin timeout', but lacks critical details such as whether the operation is async, what side effects occur, or if it is idempotent. The multi-step nature is hinted but not expanded.

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

  Conciseness4/5

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

  The description is a single efficient sentence conveying the action, resource, and a notable behavior (no timeout). The 'NUEVO:' prefix is unnecessary but does not harm conciseness. Information is front-loaded.

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

  Completeness2/5

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

  Given the tool has three parameters, no output schema, and no annotations, the description should provide more comprehensive context. It fails to explain what Hedra is, what the output of step 1 is, or how subsequent steps relate. The workflow is vaguely indicated as '3 steps' but not elaborated.

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

  Parameters3/5

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

  Schema description coverage is 100%, so each parameter is already documented. The tool description adds no additional meaning or context for the parameters. Baseline score of 3 is appropriate as the schema carries the information.

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

  Purpose5/5

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

  The description clearly states the action 'Inicia generacion de video en Hedra' (start video generation) and identifies the resource as Hedra, with a note that it is the first of three steps. This verb+resource structure effectively distinguishes it from sibling tools like check_video_status or generate_complete_foxbrizio_video.

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

  Usage Guidelines2/5

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

  The description offers no guidance on when to use this tool versus alternatives. It labels itself as 'Paso 1 de 3' but does not explain what the other steps are or when to prefer this over generate_complete_foxbrizio_video. No prerequisites or exclusions are mentioned.

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

• generate_foxbrizio_scriptB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description is the only source for behavioral details. It states that a script is generated but does not disclose return format, input requirements (e.g., minimum number of tweets), or potential side effects. The agent is left without a clear picture of what to expect from the tool.

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

  Conciseness5/5

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

  The description is a single, focused sentence that immediately conveys the core action and input source. Every word contributes to understanding, with no redundancy or unnecessary padding.

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

  Completeness2/5

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

  The tool lacks an output schema and annotations, and the description is minimal. It does not explain the return format or how this step fits into the overall Foxbrizio video generation pipeline. The limited context makes it hard for an agent to confidently invoke the tool in the right sequence.

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

  Parameters3/5

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

  The schema already provides detailed descriptions for all four parameters (style, topic, tweets, word_count), giving 100% coverage. The description adds no extra semantic value beyond what the schema already contains, 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.

  Purpose5/5

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

  The description clearly states the verb 'genera' (generate) and the specific deliverable 'script épico de Foxbrizio Romano', anchored on 'tweets de Fabrizio Romano'. This distinguishes it from sibling tools like generate_foxbrizio_audio or generate_foxbrizio_caption, 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.

  Usage Guidelines2/5

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

  The description gives no explicit indication of when to use this tool versus alternatives such as generate_foxbrizio_caption or generate_complete_foxbrizio_video. There are no mentions of the generation pipeline, prerequisites, or exclusions, so the agent must infer usage solely from the tool name.

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

• download_completed_videoB
  3.3/5.0
  Behavior2/5

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

  No annotations exist, so the description alone must cover behavioral traits. It mentions downloading and caption generation but does not specify the output format (e.g., file, URL, caption text), authentication requirements, side effects, or error handling. The agent is left uninformed about what to expect from invocation.

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

  Conciseness4/5

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

  The description is very concise at 8 words in Spanish, efficiently conveying the action and step sequence. It is front-loaded with 'NUEVO'. While not highly structured, every part contributes to understanding. Minor deduction for lack of separation between download and caption generation details.

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

  Completeness2/5

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

  Given no output schema and a 1-parameter input, the description should explain return values (e.g., file content, caption string) and prerequisite conditions (e.g., video must be fully processed). The sibling tools include check_video_status, but no guidance is given to use it before calling this tool. The 'Paso 3 de 3' hint is insufficient for full contextual completeness.

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

  Parameters3/5

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

  Schema coverage is 100% with the single parameter 'generation_id' described as 'ID de generacion del video completado'. The description adds no additional meaning or context beyond what the schema already provides, so baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool downloads a completed video and generates a caption, and identifies it as 'Paso 3 de 3', providing sequential context. This distinguishes it from siblings like generate_foxbrizio_caption (which may focus only on caption generation) and check_video_status (which checks readiness).

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

  Usage Guidelines3/5

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

  The description implies usage as the final step in a three-step process ('Paso 3 de 3'), but does not explicitly state when to use versus alternatives (e.g., check_video_status if video not ready) or preconditions (e.g., generation_id must correspond to a completed video). No contraindications or alternative tool references are provided.

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

• select_foxbrizio_presenterB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description must fully disclose behavior. It states 'select and validate' but does not explain what validation entails, what side effects occur (if any), or whether the tool is read-only or destructive. The parameter validate_only hints at a processing distinction, but the description lacks clarity about the tool's overall impact.

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

  Conciseness5/5

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

  The description is a single sentence of 10 words, front-loading the core action and resource. Every word contributes meaning. It is appropriately brief for a simple tool.

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

  Completeness3/5

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

  Given the tool has 2 parameters, no output schema, and no annotations, the description provides the basic purpose but omits important context: what the tool returns, what 'validate' means, what 'processing for Hedra' involves, and how this fits into the video generation pipeline. It is adequate but not complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so baseline is 3. The description adds context that the presenter number is for video generation, but the schema already describes the number range and the validate_only parameter. The added value is minimal.

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

  Purpose5/5

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

  The description clearly states the action (select and validate), the specific resource (Foxbrizio presenter), and the allowed range (1-9). It differentiates from sibling tools by focusing on presenter selection, which is a prerequisite for video generation, unlike tools like generate_foxbrizio_script or download_completed_video.

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

  Usage Guidelines2/5

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

  The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention that it should be used before generating a video, nor does it explain when validation-only mode is appropriate. The context of the pipeline is missing.

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

• check_video_statusA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description alone must convey behavioral traits. It only says 'check progress' without explaining whether the call is synchronous, what side effects exist (if any), or how the result is structured. This is insufficient for an agent to understand the tool's behavior.

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

  Conciseness4/5

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

  The description is extremely concise, consisting of a single sentence plus a step label. It is front-loaded with the key purpose and step context. The 'NUEVO' prefix is minor and does not detract significantly. It could be more structured but is efficient.

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

  Completeness2/5

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

  Despite having only one parameter and no output schema, the description lacks important context such as what the tool returns (e.g., status, progress percentage, error states) and whether it can be called repeatedly. The sibling tools hint at the pipeline, but the description itself is too minimal to be fully complete.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with the parameter's description already explaining its origin ('obtenido de start_video_generation'). The tool description adds no additional meaning beyond that, 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.

  Purpose5/5

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

  The description uses the clear verb 'Verifica' (check) and specifies the resource 'progreso de generacion de video' (video generation progress). It also notes 'Paso 2 de 3', which immediately distinguishes it from siblings like 'start_video_generation' (step 1) and 'download_completed_video' (step 3).

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

  Usage Guidelines4/5

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

  The description implicitly states when to use this tool by labeling it as step 2 of a 3-step pipeline. The parameter description further clarifies that the generation_id comes from 'start_video_generation'. However, it does not explicitly state when not to use it or mention alternatives.

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

• generate_complete_foxbrizio_videoA
  3.5/5.0
  Behavior2/5

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

  The description only mentions possible timeout and that it's legacy. With no annotations provided, the description should carry full burden for behavioral disclosure. It fails to state that generation creates a new resource (implied by 'complete video'), any destructive actions, authorization needs, or what happens on timeout. The information is minimal.

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

  Conciseness5/5

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

  The description is extremely concise at one sentence, with no wasted words. It front-loads the most critical information (LEGACY, alternative tool, timeout warning). Every word serves a purpose.

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

  Completeness3/5

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

  Given the tool's complexity (4 params, no output schema, no annotations), the description leaves significant gaps. It doesn't explain return behavior, what happens on timeout, or how this differs from start_video_generation beyond being legacy. The sibling tool start_video_generation exists but differences aren't explained. The timeout warning is useful but insufficient for a generation tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all parameters have descriptions. The tool description adds no additional meaning beyond what the schema provides (e.g., no clarification on when audio_path is needed or how generate_caption affects output). Baseline 3 is appropriate since schema does the heavy lifting.

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

  Purpose4/5

  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 video, flags it as LEGACY, and directs the agent to use 'start_video_generation' instead. The verb+resource (Genera video completo) is specific, though it lacks differentiation from start_video_generation beyond being legacy.

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

  Usage Guidelines4/5

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

  The description explicitly notes this is legacy and provides the alternative tool to use ('start_video_generation'). It also warns about potential timeout. This gives clear guidance against using this tool unless necessary, but no when-not-to-use details beyond legacy status.

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

• search_fabrizio_tweetsA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the burden. It discloses that the tool searches recent tweets in a database, which implies a read-only operation, but it does not explain sorting, pagination, or any limitations. The behavioral traits are minimally described.

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

  Conciseness5/5

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

  The description is a single clear sentence with no unnecessary words. It is front-loaded with the verb and resource, making it highly efficient.

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

  Completeness3/5

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

  This is a simple search tool with all parameters documented, but there is no output schema and no guidance on result format. The description also does not clarify the difference from 'scrape_fabrizio_tweets', leaving some contextual gaps for a fully informed tool selection.

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

  Parameters3/5

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

  Schema coverage is 100%, with each parameter having a description. The tool description adds no additional meaning about parameters, 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.

  Purpose5/5

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

  The description uses a specific verb ('Busca') and clearly states the resource: recent tweets about a specific topic in the database. It distinguishes itself from sibling tools like 'scrape_fabrizio_tweets' by explicitly mentioning the database, 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.

  Usage Guidelines3/5

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

  The description implies usage (querying stored tweets by keyword), but it does not explicitly state when to use this tool versus alternatives like 'scrape_fabrizio_tweets' or when not to use it. No clear when/when-not guidance is provided.

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