Server Quality Checklist

Tool Scores

• scrape_websiteC
  2.6/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but only names the API. It does not disclose behavior like rate limits, authentication needs, whether results are scraped from a website, or output structure. Lacks essential transparency.

  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 with no wasted words. However, it errs on the side of under-specification, but conciseness itself is appropriate.

  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 annotations, and no output schema, the description is far too minimal. It does not cover parameter semantics, usage context, or return values, leaving significant gaps.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must explain parameters. It only mentions 'query' generically and ignores 'gl', 'num', and 'page' entirely. Fails to add meaning beyond the schema's simple parameter names.

  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 a verb ('Fetch'), resource ('search results'), and method ('using Google Serper API'). However, the tool name 'scrape_website' suggests scraping websites, which conflicts with the description's focus on search results, slightly undermining clarity.

  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 versus alternatives (e.g., the sibling profile getters). The description implies use for fetching search results but gives no context or exclusions.

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

• get_facebook_profileC
  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 'public URL' hinting at accessibility, but does not disclose return format, authentication needs, error behavior, or rate limits. This is a significant gap for a fetch 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, front-loaded sentence with no filler. It efficiently communicates the core purpose, making it highly concise.

  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?

  With no output schema or annotations, the description should explain what data is returned and any limitations. It doesn't. The sibling tools suggest different profile types, but this description doesn't clarify how this tool fits in, leaving the context incomplete.

  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 has no description for 'profile_url', and the description only adds that it is a public URL. It does not clarify the expected format (e.g., full URL vs username) or any constraints, providing minimal compensation for the 0% schema coverage.

  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 fetches Facebook profile data for a public URL, using a specific verb and resource. It distinguishes itself from siblings by platform (Facebook vs Instagram, personal, company), though it doesn't specify what 'profile data' includes.

  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 explicit guidance on when to use this tool versus the sibling tools. The description only states what it does, not when to choose it over alternatives or any exclusions (e.g., not for private profiles).

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

• get_company_profileB
  3.4/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It simply says 'Fetch full LinkedIn company page data' but does not explain any behavioral traits such as authentication requirements, rate limits, error handling, or the structure of the returned data. The adjective 'full' hints at completeness but adds little actionable detail.

  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 extraneous words. It is front-loaded with the action and resource, making it easy to parse quickly. This is appropriately concise for the tool's simplicity.

  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 that there is no output schema and no annotations, the description is insufficient for an agent to fully understand the tool's behavior. It does not mention what 'full company page data' includes, the format of the response, potential errors, or any preconditions (e.g., URL format validation). The tool is simple, but the lack of contextual detail reduces its 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?

  The schema has 0% description coverage, so the description must compensate. It mentions 'for a given URL,' which clarifies that the linkedin_url parameter should be a LinkedIn company page URL. However, it does not provide format expectations or examples, and the parameter name itself already conveys most of the meaning.

  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's function: 'Fetch full LinkedIn company page data for a given URL.' It uses a specific verb ('fetch') and resource ('LinkedIn company page data'), and it distinguishes itself from siblings like get_personal_profile and get_facebook_profile by focusing on company pages and LinkedIn specifically.

  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 for LinkedIn company URLs but does not explicitly state when to use it over alternatives like get_personal_profile or scrape_website. There is no mention of exclusions or alternative tools, leaving the agent to infer the appropriate context from the resource type mentioned.

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

• get_instagram_profileB
  3.4/5.0
  Behavior2/5

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

  Annotations are absent, so the description carries the full burden of behavioral disclosure. It only notes the profile must be 'public', which hints at a limitation, but does not mention return format, rate limits, error behavior, or what data is included. This is sparse for a tool with no structured behavioral annotations.

  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 with no unnecessary words. It front-loads the verb and resource, then specifies the input format. It is concise without sacrificing clarity.

  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?

  With no output schema, the description should explain what 'profile data' includes, but it remains vague. It also lacks details on limitations for private profiles, expected errors, or result structure. While the tool is simple, the description is under-specified for an agent to know what to expect.

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

  Parameters4/5

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

  The schema has zero description coverage, but the description compensates by adding meaning to 'instagram_url_or_username': it clarifies the string can be either a username or a URL, and must be public. This goes beyond the bare type string, giving the agent essential usage context.

  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 specific verb 'Fetch' and clearly identifies the resource as 'Instagram profile data', with a parameter accepting a username or URL. This distinctly separates it from sibling tools like get_facebook_profile and scrape_website, making the tool's purpose immediately clear.

  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 implies the tool is used when you need Instagram profile data, but provides no explicit guidance on when to use it versus alternatives like get_personal_profile or scrape_website. There are no stated exclusions or comparison to sibling tools, leaving the agent to infer usage context.

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

• get_personal_profileA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of disclosing behavior. 'Fetch' clearly implies a read-only operation with no side effects. However, it does not mention potential limitations (e.g., private profiles, authentication needs, or failure modes) or describe the output format.

  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, front-loaded sentence that states the action and resource without unnecessary words. It is concise and well-structured.

  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?

  The tool is simple with one parameter and no output schema. The description defines the input and purpose, but it does not hint at the shape of the returned profile data or any error conditions. It is adequate but could be more complete.

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

  Parameters4/5

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

  With schema coverage of 0% and only one parameter, the description adds meaning by stating 'for a given URL', indicating that the linkedin_url parameter expects a LinkedIn profile URL. This is helpful guidance for the single parameter.

  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 ('Fetch') and clearly identifies the resource ('full LinkedIn personal profile data'). It distinguishes from sibling tools by specifying 'LinkedIn personal' versus company, Facebook, or Instagram profiles.

  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 implies when to use this tool: when a LinkedIn personal profile is needed, given the sibling tools cover other platforms. It does not explicitly name alternatives or exclusions, but context is clear.

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