MSPStuff Switchboard

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

The readOnlyHint annotation already establishes the safe read-only nature. The description adds useful context by disclosing the specific report contents, including unhealthy indicators (no recent backup, failed boot check), but it does not cover return format, pagination, or any other behavioral trait beyond what the annotation implies.

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?

A single front-loaded sentence lists exactly what the tool reports with no wasted words. It is appropriately sized for a simple status tool.

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?

With no output schema, the description must convey return content, and it does: device list, healthy count, and flagged issues. Filtering and row limits are left to the schema, which documents them fully. Only minor details such as response format are absent, making it nearly complete for this low-complexity 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%, so both the limit and client parameters are fully documented in the schema. The description adds no additional parameter meaning, which is the baseline expectation when the schema already does the heavy lifting.

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 names the resource (backup status) and specifies the content of the report: protected devices, healthy count, and devices with no recent backup or failed boot check. It is clearly distinguishable from siblings like patch_status or security_posture by domain, though it does not explicitly contrast with them.

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?

There is no when-to-use guidance, no mention of alternatives, and no conditions that would select this tool over siblings such as health_findings or estate_overview. Usage is only implied by the description of outputs.

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?

readOnlyHint=true already establishes the safety profile, so the description's job is to add context — and it does, enumerating the returned content (linkages, devices, tickets, backups). It omits anything about auth scope, result size, or truncation behavior, but for a read-only aggregator this is reasonably transparent.

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?

Two sentences, zero filler, with the primary scope stated first and the default mode second. Every clause carries information an agent can act on.

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 two-parameter, read-only overview tool with no output schema, the description covers what is returned and how the optional client parameter changes behavior. The limit parameter's effect on output is left entirely to the schema, which is a minor gap.

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 both parameters are already documented; the description's only added nuance is the no-client default, which the schema also states ('Leave it out for the whole company'). Baseline 3 applies since the description adds little beyond structured fields.

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?

States a specific resource and scope: one client's cross-platform linkage, devices, tickets and backups. The 'One client' framing implicitly separates it from estate_overview's whole-estate scope, but it never names that sibling or any other, so an agent must infer the boundary.

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?

'With no client named, lists the clients' gives clear conditional usage for the two modes of the tool, and the schema reinforces this. It stops short of naming alternatives (e.g. estate_overview for the whole company) or stating when not to use it.

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 readOnlyHint=true annotation already tells the agent this is a safe, non-mutating read, so the description does not need to restate safety. It adds only modest behavioral context (that the result is an aggregate count view with a 'most offline' ranking), and says nothing about whether counts are live or cached, or how the limit interacts with the ranking.

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?

A single compact sentence that front-loads the reported facts with no filler. It is efficient, though as a fragment it lacks the connective framing that would make the ordering of returned information explicit.

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?

With no output schema, the description must carry the return-shape burden, and it only partially does: it names count metrics and a ranking, but leaves ambiguous whether the response is a single summary object or a list of client rows, and how 'limit' shapes that output. It is adequate for a simple read tool but not 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 description coverage is 100%, so both parameters are already documented in the schema (limit default/max, client name or initials). The description adds no syntax or semantics beyond implying that results are grouped by client, which is the correct baseline of 3 when the schema does the heavy lifting.

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 precisely what the tool reports: device counts, online/offline split, and the clients with the most offline devices. This is a clear content-level purpose, but it never distinguishes itself from the closely named sibling client_overview, so an agent must infer the boundary.

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?

There is no explicit when-to-use or when-not-to-use guidance in the description. Nothing points to client_overview for per-client detail or explains how the optional client filter changes the use case; the schema's 'Leave it out for the whole company' is the only routing hint and it lives in a structured field, not the description.

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 provide readOnlyHint=true, confirming it's a safe read operation. The description adds 'worst first' and 'in plain words', which hints at sorting and summarization behavior, but doesn't detail return format, pagination, or what 'plain words' means, leaving gaps for a read-only tool.

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?

A single efficient sentence that front-loads the core idea. It's appropriately sized, though the phrase 'in plain words' is somewhat informal and could be more precise.

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 cross-platform aggregate nature and lack of output schema, the description is too sparse. It doesn't explain what constitutes a 'finding', how results are structured, or how they relate to sibling tools, leaving significant gaps for proper invocation.

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 single 'limit' parameter is fully documented in the schema. The description adds no parameter details beyond what the schema provides, meeting the baseline.

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 vaguely states it surfaces 'what needs attention' across platforms, which is a purpose but lacks a specific verb and resource. It doesn't clearly distinguish from siblings like security_posture or backup_status, which also cover health-related concerns.

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?

No guidance on when to use this tool versus alternatives. With several sibling tools covering specific domains, the description doesn't indicate that this is a cross-platform aggregate or when an agent should prefer it over domain-specific tools.

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 readOnlyHint annotation already establishes this is a safe, non-mutating operation, so the description does not need to carry the safety burden. It adds the substantive behavioral fact that the tool surfaces mismatches between purchased and billed seats, which is real context, but says nothing about result shape, freshness of the billing data, or how mismatches are presented.

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?

A single tight sentence with no filler, and the scoping ('per client') is front-loaded. It loses a point only because the elliptical, verbless phrasing reads like a column header rather than a complete statement of what the tool does.

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?

With no output schema and no annotations beyond readOnlyHint, the description is the only source for what the tool returns, yet it never states the output form (table, per-client rows, mismatch flags). For a reporting tool this leaves a meaningful gap, though the domain and scope are at least clear enough to invoke it 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 description coverage is 100%, so both parameters (limit and client) are fully documented in the schema, including defaults and the max of 50. The description's 'per client' phrasing adds nothing beyond what the client parameter description already says about omitting it for the whole company.

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 fragment names a specific domain (Microsoft 365 seat counts compared against purchased and billed quantities, plus mismatches), which clearly separates it from siblings like patch_status or security_posture. However, it is a noun phrase with no verb — an agent cannot tell whether this returns a report, a list, or a reconciliation summary. Purpose is inferable but not stated.

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?

There is no explicit when-to-use guidance, no mention of alternatives among the seven sibling tools, and no exclusions. The only scoping hint ('per client') is implicitly restated from the client parameter rather than framed as usage guidance.

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, so the safety profile is covered and the bar is lower. The description adds that the report is scoped by client and ranks laggards, but says nothing about return format, freshness of data, or aggregation 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?

A single front-loaded sentence with no filler; the resource and its scope lead the sentence. It is efficient, though slightly compressed for a reporting tool.

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?

With no output schema, the description must convey what comes back, and it does sketch the shape (per-client up-to-dateness plus a lagging-clients signal). For a read-only, two-optional-parameter tool this is close to sufficient, missing only the concrete metric or format of "how up to date."

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%, and both limit and client are fully documented there, including the default/max and the "initials" shorthand. The description's "by client" phrasing mirrors the schema without adding syntax or edge-case detail, so the baseline 3 applies.

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 names a specific resource (Windows patch status), its grouping dimension (by client), and the two things it reports: currency of devices and which clients lag. That is enough to separate it from backup_status or security_posture, though it does not explicitly name those siblings.

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?

"Which clients are furthest behind" implicitly signals the prioritization use case, so an agent can infer when this report is relevant. There is no explicit when-to-use, when-not-to-use, or routing to an alternative such as security_posture or estate_overview.

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 establish readOnlyHint=true, so the safety profile is covered. The description adds the substantive content scope (EOL/EOS operating systems and KEVs), which is genuinely useful context, but says nothing about ordering, result shape, or how the two data categories are combined in the output.

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?

A single dense sentence with no filler, and the most important content (what is reported) is front-loaded. It is efficient, though the absence of a verb makes it read more like a label than an instruction.

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, one-parameter listing tool with no output schema, the description covers the subject matter but leaves the agent guessing about the report's structure, whether devices and vulnerabilities are interleaved, and how it differs from sibling security/patch tools.

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% and the single 'limit' parameter is fully documented in the schema. The description adds no additional parameter meaning, so the baseline 3 applies.

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 names the exact resource set it reports: devices on OSes past/near end of support plus known exploited vulnerabilities affecting them. That is specific and concrete, but it is a noun phrase with no verb and gives no explicit contrast against overlapping siblings like patch_status or health_findings.

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?

There is no guidance on when to reach for this tool rather than patch_status, health_findings, or estate_overview, and no stated prerequisites. The agent must infer its role purely from the noun phrase.

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?

readOnlyHint=true already declares this a safe read, lowering the bar. The description adds content-level context by naming the sections returned (open tickets, in/out flow, busiest clients, per-technician workload), which hints at an aggregated report shape. It says nothing about filtering behavior, time window, or how the client param scopes results.

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?

A single tight sentence with no filler. The content list is front-loaded, though it reads as a data inventory rather than an action-oriented statement, which slightly weakens scannability.

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 aggregated report with no output schema, the description conveys the data domains covered, which is the minimum an agent needs to route to it. It omits the time window for 'weekly flow' and any indication of whether it responds with aggregated metrics versus raw rows.

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 both limit and client are already fully documented in the schema (default 10, max 50; client name or initials, omit for whole company). The description adds no additional parameter meaning, so baseline 3 applies.

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 lists what the tool surfaces (open tickets, ticket flow, busiest clients, technician open work), which pins it to the service-desk domain. However, it is a noun-phrase fragment with no verb (report? list? summarize?), and it never distinguishes itself from sibling overview tools like client_overview or estate_overview. Purpose is inferable but not precisely stated.

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?

No when-to-use guidance, no prerequisites, and no mention of the overlapping siblings (client_overview, estate_overview, patch_status) that could also describe tickets or clients. The agent must guess when this report is preferable to those.

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