Server Quality Checklist

Tool Scores

• powerplatform_api_callC
  2.9/5.0
  Behavior2/5

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

  With no annotations present, the description carries the full burden of behavioral disclosure, but it only says to execute a call and consult documentation first. It does not mention authentication requirements, side effects of mutating methods, error behavior, rate limits, or that the tool is a raw passthrough whose behavior depends entirely on the chosen endpoint.

  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 short and front-loaded with the core action, and both sentences serve a purpose. It loses a point because 'relevant resource documentation' is somewhat vague and the overall definition is thin for a tool that delegates to a large API surface.

  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?

  For a generic API execution tool with no output schema and no annotations, the instruction to read the skill and resource documentation first is a useful mitigation, but the description still lacks direct context about return values, permission expectations, or the range of Power Platform APIs it can reach. It is adequate but leaves meaningful gaps for the agent to discover elsewhere.

  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 the schema already documents method, endpoint, body, and environment_id. The description adds no parameter-level meaning, but it does not need to; the baseline of 3 is appropriate when the schema carries the parametric load.

  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 identifies the action as executing a Power Platform API call, which distinguishes it from the sibling graph_api_call tool by platform. It also directs the agent to first read the powerplatform-api skill, reinforcing what the tool targets. It stops short of a 5 because it does not explicitly contrast itself with graph_api_call or describe its generic low-level passthrough nature.

  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 only guidance offered is 'Read the powerplatform-api skill and relevant resource documentation first,' which is a prerequisite instruction rather than a usage-selection rule. It does not say when to use this tool instead of graph_api_call, list_skills, or read_skill, nor does it describe contexts where the tool is appropriate or inappropriate.

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

• graph_api_callA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description bears full responsibility for disclosing behavior, but it reveals nothing about authentication, permissions, side effects, rate limits, or response handling. It only says to read documentation, leaving the caller to infer that behavior varies by endpoint.

  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 core function first and then gives a useful prerequisite. There is no redundant or filler content.

  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 description covers the basic action and points the agent to external docs, while the schema covers all parameters. However, with no output schema and no behavior disclosure, the description leaves response format, authentication, and error behavior unspecified.

  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 are already explained in the input schema. The description adds no parameter-level meaning beyond the instruction to consult resource documentation, which meets the baseline but not more.

  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 states a specific action: 'Execute a Microsoft Graph API call.' The resource boundary (Microsoft Graph) clearly distinguishes it from sibling powerplatform_api_call, and the verb + resource combination is 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?

  No explicit guidance is given about when to choose this tool over powerplatform_api_call or other siblings. 'Read the graph-api skill and relevant resource documentation first' is a prerequisite instruction, not a selection rule, though the Microsoft Graph scope implies the intended context.

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

• list_skillsA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It accurately conveys that the tool returns available skills and resource references, and it clarifies what those items contain. It does not mention side effects, ordering, caching, or whether the list is exhaustive, but for a simple zero-parameter list operation this is acceptable but not deeply transparent.

  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 the primary behavior, and each sentence adds useful information: what is returned and what those returned items mean. No filler or redundancy.

  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?

  For a parameterless list tool, the description gives enough context to understand the output domain: skills are API patterns/best practices and resources are endpoint-specific docs. The absence of an output schema is partially mitigated by this description, though it does not describe response format or pagination.

  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 zero parameters and schema coverage is 100%, so there are no parameter semantics to document. The description earns its points by explaining what the returned data represents, which is the main semantic value an agent needs.

  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 uses a clear verb ('Returns') and names the resources ('skills and resource references'), with additional explanation of what skills and resources are. It is distinguishable from read_skill by being a list operation, though it does not explicitly contrast itself with siblings.

  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 phrase 'Returns available skills and resource references' implies a discovery/list use, which an agent can infer as a precursor to read_skill, graph_api_call, or powerplatform_api_call. However, the description does not explicitly state when to use this tool versus alternatives or give any exclusions.

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

• read_skillA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description must carry the behavioral burden. It communicates that the tool loads a reference into context, implying a read-only action, and that it is preparatory rather than an actual API call. However, it does not describe what the agent should expect afterward—e.g., whether documentation is returned, how it is formatted, or whether context is replaced or appended.

  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 convey both function and usage guidance with no filler. The core action is front-loaded, and the use case is stated immediately, making the description easy to process.

  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?

  For a low-complexity, two-parameter tool with full schema coverage, the description is largely complete. It explains what the tool does, its purpose, and its place in the workflow relative to API calls. It could be improved by explicitly addressing the sibling list_skills or clarifying the absence of side effects, but nothing critical is missing for correct invocation.

  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 already documents both parameters with full coverage, including an enum and examples. The description adds no additional parameter-level semantics beyond tying the concepts of 'skill' and 'resource' to the corresponding parameters. Baseline 3 is appropriate because the 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 a specific verb ('Loads') and resource ('a skill or resource reference') and adds purpose ('to learn API patterns before making calls'). It does not explicitly differentiate itself from list_skills, but the purpose clause makes the distinction from the *api_call siblings reasonably clear.

  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 second sentence gives explicit usage context: use this before making calls to learn API patterns. It does not mention when not to use it or explicitly name alternatives like list_skills, but the timing and purpose are clear enough for an agent to select it over the API-call siblings.

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