Server Quality Checklist

Tool Scores

• linkedin_get_profileA
  3.9/5.0
  Behavior3/5

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

  Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds no further behavioral details (e.g., rate limits, data freshness). It lists sections but that's more about parameters.

  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?

  Single sentence, front-loaded with the tool's purpose. All listed sections are relevant. Could be slightly more structured, but concise overall.

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

  Completeness4/5

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

  The tool has 2 optional parameters and an output schema (not shown). The description covers the main return content well. Given the tool's simplicity, it is sufficiently 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 coverage is 100%, with both parameters well-documented. The description adds minimal extra meaning beyond what's in the schema (e.g., implicit listing of sections).

  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 retrieves the user's LinkedIn résumé and lists many sections (bio, work history, education, etc.). It distinguishes from siblings (get_activity, get_section, etc.) by focusing on the full professional profile.

  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 says 'Use for questions about who they are professionally, their background, or qualifications,' which gives clear use context. However, it does not explicitly exclude use cases or mention when to prefer sibling tools like get_activity.

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

• linkedin_get_sectionA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds that section names are case-sensitive and returns raw data, which is useful but minimal 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.

  Conciseness5/5

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

  The description is extremely concise with two sentences, front-loading the core purpose. Every sentence adds value: the first states the function, the second provides usage guidance and a key constraint (case-sensitivity). No extraneous information.

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

  Completeness4/5

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

  Given the tool has 2 well-documented parameters, an output schema (present per context signals), and rich annotations, the description covers the essential purpose and use case. It mentions 'raw API response', which is helpful. It could be slightly more complete by hinting at output format, but the existing output schema handles that.

  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 100% schema description coverage, the schema already documents both parameters (domain enum with all values, maxPages with default/range). The tool description mentions 'exact name' and 'case-sensitive', reinforcing the schema but not adding new semantic meaning beyond it.

  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 'Get', the resource 'single LinkedIn section', and emphasizes 'by exact name', 'raw API response', and case-sensitivity, which distinguishes it from siblings like linkedin_get_profile and linkedin_get_activity.

  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 says 'Use when you need one specific section or the raw API response', providing clear context for when to use the tool. It does not explicitly state when not to use or name alternatives, but the sibling tools in the context help fill that gap.

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

• linkedin_get_activityA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate read-only, open-world, idempotent, non-destructive. The description adds that the response can be large and suggests limiting scope via specific sections. 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.

  Conciseness5/5

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

  Two concise sentences: first states purpose and enumerates activity types, second provides usage guidance and a caveat. No filler, front-loaded, every sentence earns its place.

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

  Completeness4/5

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

  Covers purpose, usage, and a size warning. Output schema handles return value descriptions. Lacks mention of authentication or rate limits, but annotations cover safety. Very complete for an activity tool with rich schema.

  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 detailed explanations for each parameter (e.g., enum values for domains, range for maxPagesPerDomain). The description does not repeat schema but adds a meta-hint to prefer specific sections. Baseline 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 gets the user's LinkedIn social activity, enumerating specific categories (connections, posts, etc.) and usage context ('Use for questions about their network, content, or job search'). It distinguishes from siblings like linkedin_get_profile and linkedin_get_section by focusing on aggregate activity.

  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?

  Provides clear usage context: 'Use for questions about their network, content, or job search.' Advises to 'prefer specific sections — these can be large,' guiding the agent to request only needed domains. Lacks explicit when-not-to-use or alternatives but is sufficient.

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

• linkedin_get_recent_changesA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds context about the 28-day window and polling mechanism, which is complementary and does not contradict 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?

  Two concise sentences with clear front-loading of purpose. No unnecessary words, every sentence adds value.

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

  Completeness5/5

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

  With 3 parameters, no required, and an output schema, the description is complete. It explains the 28-day window, polling, and fallback action, leaving no critical gaps for agent invocation.

  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?

  All three parameters have schema descriptions (100% coverage). Description adds value by explaining the polling usage of startTime and the meaning of the time window, enhancing understanding beyond schema.

  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?

  Description clearly states it retrieves user LinkedIn data changes from the past 28 days, with specific examples (profile edits, new connections). It distinguishes itself from sibling tools like linkedin_get_profile or linkedin_get_activity.

  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?

  Explicitly mentions incremental polling via nextStartTime and suggests running linkedin_check_access if empty. However, it does not explicitly state when not to use this tool or compare to alternatives beyond the polling hint.

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

• linkedin_check_accessA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description reinforces these by stating it checks access without mutation, and adds context about error diagnosis, which is valuable 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.

  Conciseness5/5

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

  Two short sentences, front-loaded with purpose, no waste. Each sentence earns its place.

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

  Completeness5/5

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

  For a simple no-parameter tool, the description covers purpose and use case completely, even without an output schema.

  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 tool has 0 parameters and schema coverage is 100%, so the description adds no parameter details, which is acceptable. Baseline for 0 params is 4.

  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 'Check whether the user has granted LinkedIn data access to this app.' This is a specific verb+resource, and it distinguishes from siblings (which retrieve data) by focusing on access diagnosis.

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

  Usage Guidelines5/5

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

  The description explicitly tells when to use: 'Use to diagnose missing data or 403 errors before retrying other tools.' This provides clear context and exclusions.

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