Jackrabbit Class MCP by usefulapi

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the description's non-idempotency note is partly redundant — but spelling out the concrete consequence ('calling twice creates two students') is a real value-add beyond the hint flag. It also contributes the 'existing family' prerequisite that no annotation conveys.

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 compact clauses, front-loaded with the operation class and verb, with zero filler. Every element (mutation status, target entity, idempotency consequence, requirement, endpoint) carries information.

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 is silent on what a create call returns — notably whether the new student's id comes back, which an agent needs to chain into follow-up calls. For a 10-parameter mutation tool this leaves a meaningful gap, though annotations cover the safety profile.

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% and every property is documented, so the schema does the heavy lifting. The description only restates the two required fields (family_id, first_name) already marked required in the schema, adding no format or lookup guidance beyond what's there.

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 verb and resource ('add a new student to an existing family in Jackrabbit') plus the HTTP endpoint, which is enough to distinguish it from jackrabbit_get_student and jackrabbit_create_waitlist_entry. The 'WRITE:' prefix immediately signals the operation class.

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?

It gives a usable precondition ('existing family', requires family id and first name), which implies usage but never states when to use this versus the sibling write tool (jackrabbit_create_waitlist_entry) or to look up a family first. No explicit exclusions or alternative routing.

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 idempotentHint=false, but the description goes further by naming the concrete failure mode (HTTP 409 when the student is already waitlisted) and by clarifying the side-effect boundary (no enrollment). It omits permission/auth requirements and how a supplied position interacts with existing entries, keeping it out of the top band.

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, front-loaded with the WRITE marker and the core action, then the failure mode, then the endpoint. No filler sentences and nothing buried.

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 4-parameter create tool with full schema coverage and annotations covering safety and idempotency, the key gaps an agent faces – duplicate handling and non-enrollment semantics – are covered. Only the success response shape is unaddressed, and with no output schema that is a minor omission.

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% – class_id, student_id, notes and position are all documented in the schema, including the default for position. The description adds nothing beyond the schema for any parameter, 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?

"WRITE: put a student on a class waitlist" gives a specific verb and resource, and "Does not enroll the student" draws the boundary against the nearest mistaken action (enrollment). The sibling list has no overlapping create sibling that could confuse it, so an agent can select it unambiguously.

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?

It states the effect and the negative case ("Does not enroll"), which effectively rules out using it as an enrollment tool. It stops short of naming an alternative (e.g., an enroll tool) or stating prerequisites such as the class needing to be full, so it is clear context without explicit alternatives.

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, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered without the description's help. The description contributes the scope of the response (schedule, capacity, fees, registration settings), which is useful but modest added context; it says nothing about error behavior for missing ids or rate limits.

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 short sentences, front-loaded with the payload summary before the endpoint path. The raw 'GET /v1/Classes/{id}' line is mildly redundant with the name and title, but it is not wasteful or padded.

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 simple single-resource read with full schema coverage and no output schema, the description adequately signals what comes back by naming the four payload areas. Nothing an agent needs in order to invoke it correctly is missing, though a note on missing-id behavior would have rounded it out.

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% and the single class_id parameter is documented as a positive Jackrabbit class id with bounds, so the schema does the work. The description only restates 'by id' without adding format, source, or lookup guidance, matching the baseline for fully-covered schemas.

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 verb and resource ('One class by id') and enumerates the returned payload ('full schedule, capacity, fees and registration settings'), which clearly separates it from the listing sibling jackrabbit_list_classes and from jackrabbit_get_class_roster. It stops short of naming any sibling explicitly, so it is clear but not maximally differentiated.

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?

Usage is only implied: fetch one class when you have its id, versus listing when you don't. There is no explicit when-to-use statement, no prerequisite or permission note, and no reference to alternatives such as jackrabbit_list_classes or jackrabbit_get_class_roster.

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 and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral content: the 'today' time scoping (with no date parameter, the agent knows it cannot query arbitrary dates) and the exact response contents, which no output schema provides.

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?

One front-loaded sentence plus the REST path; every element earns its place and the returned-field inventory is efficient. The telegraphic 'Who is in a class today:' opening is slightly terse but not padded.

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 small read-only tool with no output schema, the description compensates well by spelling out the response fields. Remaining gaps are minor: no mention of pagination, behavior for an invalid/unknown class_id, or whether 'today' is timezone-dependent.

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% with a single well-documented class_id parameter, so the description need not carry this burden. It only echoes the id via the endpoint path '/v1/Classes/{classId}/roster', adding no format or sourcing detail beyond the schema — baseline 3.

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 and verb-equivalent ('Who is in a class today') and then enumerates the returned fields (class name, start time, location, room, instructors, roster). This distinguishes it reasonably from jackrabbit_get_class and the list_* siblings, though it never explicitly says how it differs from get_class.

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?

Usage is only implied by 'Who is in a class today' — an agent can infer this is the call for attendance/roster questions. There is no explicit when-to-use, no named alternative (e.g. jackrabbit_list_attendance vs jackrabbit_get_enrollment), and no statement of prerequisites beyond the required class id.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds only the raw endpoint path (GET /v1/Contacts/{id}), with no mention of not-found behavior, permissions, or response shape—essentially nothing beyond structured fields.

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 short fragments with zero waste and the key fact (single contact by id) front-loaded. It is terse to the point of being skeletal, but nothing is padded.

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 simple one-parameter read tool with annotations covering safety, the description is minimally sufficient. It still omits what the returned contact contains and what happens on an invalid id, gaps an agent may care about when chaining calls.

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% and the single parameter contact_id is documented as "Jackrabbit contact id" with a positive-integer constraint. The description adds no meaning beyond that, 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?

"One contact by id" states the resource and the single-record scope, which implicitly distinguishes it from jackrabbit_list_contacts. However, it never names the sibling or explicitly frames the verb, so the differentiation is inferred rather than 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 guidance on when to use this versus jackrabbit_list_contacts or jackrabbit_list_authorized_contacts, nor any prerequisite such as needing a known contact_id. The agent must infer usage entirely from the name and schema.

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 annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the endpoint and confirms that the response covers five family and five student fields, but does not describe authentication needs, rate limits, or the exact response structure.

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?

The description is a single tight sentence plus the endpoint reference, with the substantive information front-loaded and no wasted words.

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 simple zero-parameter read tool, the description conveys the scope of the returned labels and names the relevant fields. It stops short of spelling out the response shape, but that is a minor omission given the tool's simplicity and the absence of an output schema.

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?

This tool has zero parameters and a 100% schema description coverage baseline. The description does not need to explain parameter behavior, and it correctly focuses on the returned data instead.

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 identifies a specific resource: the organization's labels for five family and five student user-defined fields, and names the corresponding API endpoint. It is clear what the tool returns, though it does not explicitly differentiate itself from the sibling jackrabbit_list_options tool.

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?

The description implies this tool is used to retrieve custom field labels, but gives no explicit guidance on when to use it versus alternatives such as jackrabbit_list_options. There are no stated exclusions or preconditions.

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 and destructiveHint=false, and the description's GET endpoint wording is consistent with that. It adds the future-enrollment routing detail, but does not describe error behavior, permissions, or what happens when the enrollment is not found.

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?

The description is a single compact line with no wasted text. The core lookup and the future flag condition are front-loaded.

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 simple read tool with full schema coverage and read-only annotations, the definition is sufficient to invoke it correctly. It could mention not-found behavior or expected return shape, but those are minor gaps for a basic by-id lookup.

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 both parameters are already well documented. The description reinforces the future=true meaning but adds no syntax or constraints beyond what the schema provides.

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 a specific verb and resource: get one enrollment by id, with a distinct future-dated variant. It clearly separates this from list-oriented siblings such as jackrabbit_list_enrollments.

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?

It clearly indicates this is the by-id lookup and explains when to set future=true. It does not explicitly name alternatives or say when not to use this tool, but the usage context is clear.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful payload context by stating that the result includes balance, billing, discount settings, and notes, though it does not mention not-found or error 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?

Two compact fragments with no filler. The resource and scope are front-loaded, and the endpoint path is a useful, brief anchor for API-oriented agents.

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 usefully names the main categories of returned data. It does not fully describe the response shape, but for a simple single-record lookup it gives enough context to call the tool 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?

There is a single parameter with 100% schema description coverage, so the schema already fully documents family_id. The phrase 'by id' confirms the usage but adds no format or constraint detail beyond what the schema provides.

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 gives a specific verb-and-resource pair: fetch one family account by id, and enumerates the main data categories returned (balance, billing, discount settings, notes). The 'by id' scoping implicitly distinguishes it from sibling list tools like list_families, though it does not name them explicitly.

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?

Usage is only implied: you use this when you have a specific family_id and need a single account rather than a listing. It does not explicitly contrast with list_families or list_archived_families, nor does it state what to do if the id is unknown.

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, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds a genuinely useful auth prerequisite, but says nothing about aggregation granularity, currency, whether zero-revenue organizations appear, or cost/pagination 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?

Two short clauses, the auth restriction front-loaded and the scope immediately after. The raw HTTP endpoint is arguably redundant filler but is brief enough not to harm 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 two-parameter read-only report, annotations plus a full-coverage schema cover most of what an agent needs. With no output schema, the description should say more about the shape of the returned revenue summary, and it does not.

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% with both date parameters documented including format and inclusive meaning. The description only restates 'for a date range,' adding no syntax or boundary semantics beyond the schema, 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?

States a specific verb and resource: total revenue per franchise organization for a date range, backed by an explicit endpoint. This is clearly a reporting tool and is distinguishable by domain from the entity get/list siblings, though it doesn't name any sibling directly.

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?

The 'Corporate tokens only' constraint tells the agent this will fail with non-corporate credentials, which implies usage context. However, no alternatives are named and no when-not-to-use guidance is given relative to the many list/get tools in the sibling set.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that the result is scoped to the organization the token accesses, not an arbitrary org — but says nothing about failure modes for an invalid or multi-org token.

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?

One front-loaded sentence naming the resource and its returned fields, plus the endpoint for traceability. No filler, nothing that fails to earn its place.

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 carries the burden of describing return values and does so by listing name, email, default currency and logo URL — enough to decide whether to call it. Minor gap: no mention of what happens when the token is invalid or unbound to an org.

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?

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter semantics to explain and nothing to compensate for.

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?

Specific verb+resource ('The Jackrabbit organization') with the exact fields returned enumerated, so an agent knows precisely what it gets back. It does not explicitly differentiate itself from jackrabbit_list_options, which is the only plausibly confusable sibling.

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?

Usage is implied rather than stated: an agent can infer this is the call to fetch tenant/account context, but the description never says when to reach for it (e.g. before currency-dependent operations) or when to prefer list_options.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the REST path as light context, but says nothing about not-found behavior, permission requirements, or whether it returns the full record.

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 terse fragments, front-loaded with the resource and scope, with zero filler. It is arguably too terse to be fully helpful, but nothing is wasted or buried.

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 simple single-parameter read tool with full annotation coverage, the core need is met. However, with no output schema, the description could reasonably hint at what the returned staff record contains or how to handle a missing id, and it does neither.

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 staff_id parameter is documented with type and bounds. The description only restates 'by id' and adds no format, source, or lookup guidance beyond the schema, 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?

States a specific resource and scope: 'One staff member by id,' which contrasts implicitly with the sibling jackrabbit_list_staff. The endpoint mapping (GET /v1/Staff/{id}) reinforces it is a single-record fetch, but the description never names the list sibling explicitly.

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?

Usage is only implied by 'by id' — the agent can infer this is for retrieving a known staff record rather than browsing. There is no explicit statement of when to prefer this over jackrabbit_list_staff or what to do when the id is unknown.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful payload context by naming the field groups returned (profile, size, health-note), which matters since there is no output schema. It says nothing about behavior for an invalid or missing id, auth requirements, or rate limits.

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, no filler; the identifying scope comes first and the endpoint reference second. Nothing is buried or repeated.

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 one-parameter read tool with no output schema, the description gives a reasonable hint about returned field groups, but 'all profile, size and health-note fields' stays vague and there is no mention of what happens when the id does not exist. Not missing anything fatal, but thin for its role.

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% with a single documented student_id parameter, so the baseline is 3. The description adds only 'by id', which restates the schema rather than adding format or sourcing guidance.

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 verb and resource: fetch 'one student by id' plus the endpoint GET /v1/Students/{id}. 'One student' implicitly contrasts with the sibling list_students, but it never names that sibling, so the differentiation is inferred rather than 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 guidance on when to use this versus jackrabbit_list_students (e.g. when the id is unknown, list first) or versus jackrabbit_get_family for related data. The singular 'one student' is the only hint, and there are no stated exclusions or prerequisites.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description adds only the REST path (GET /v1/Families/archived) and the lead-file characterization; it says nothing about result ordering, retention, or whether archived families reappear in the main list.

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 short sentences, action first, nothing redundant. Every element earns its place, including the parenthetical qualifier.

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 paginated list with fully documented parameters and annotation coverage, the description is nearly sufficient. The residual gap is that it does not clarify the archived/active relationship with the sibling list tool or describe pagination termination, though the schema's next_page hint partially covers the latter.

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%, with page, page_size, family_id, family_name and location_id all documented inline. The description contributes no additional parameter meaning, so the baseline of 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?

States a specific verb and resource ('List archived families') and adds the clarifying gloss 'lead-file', which separates the archived population from the general families list. It stops short of naming jackrabbit_list_families as the counterpart for active records, so the distinction is inferred rather than explicit.

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 or when-not-to-use guidance. The agent must infer that this is the archived counterpart of jackrabbit_list_families, and nothing states whether an active-family search should ever fall back to this endpoint or vice versa.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered; the description adds the non-obvious semantic that records exist only where attendance was actually marked, which prevents an agent from reading an empty page as 'all present'. It stops short of describing pagination or ordering behavior, but page/page_size are documented in the schema.

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?

Three short sentences, front-loaded with purpose, then return fields, then filters, then the endpoint. Nearly every clause carries information; only the trailing 'GET /v1/Attendance.' is close to filler for an agent that cannot issue raw HTTP calls.

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 usefully enumerates the returned fields and the available filters for a 10-parameter all-optional query tool, and annotations cover safety. Remaining gaps (sort order, whether has_scheduled_makeup and did_attend_makeup interact, empty-result meaning beyond the one parenthetical) are minor.

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 the parameter baseline is 3. The description groups the filters into student, class, date range, attended and makeup status, matching most parameters, but omits page, page_size and updated_since, adding no detail beyond the schema.

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 verb and resource ('List attendance records') and then names the returned fields (student, class, date, attended, note, makeup). The parenthetical caveat that only marked-attendance dates appear meaningfully scopes it apart from roster/enrollment siblings, though it never names an alternative tool by name.

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?

The reader can infer when to use it (need attendance rows filtered by student/class/date/attendance status), and the 'only dates where someone marked attendance' note hints at when a result set will be empty. But there is no explicit when-not-to-use and no pointer to a sibling such as jackrabbit_get_class_roster for roster-style queries.

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, destructiveHint=false, and openWorldHint=true, so the description carries a lighter burden. The description adds only the raw REST path (GET /v1/Contacts/authorized/{studentId}) and nothing about ordering, empty-result behavior, or what the returned contacts look like — negligible value beyond the structured fields.

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 short fragments, tightly front-loaded with no filler; every word is relevant. Slight redundancy in restating the same resource twice (phrase + endpoint path), which is only marginally useful for API mapping.

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 one-parameter read-only lookup with full schema coverage and safety annotations, the description is adequate. It omits, however, whether the response is a list or a single object, what happens when a student has no authorized contacts, and how the returned entries relate to jackrabbit_get_contact.

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% and the single student_id parameter is documented with a description and integer bounds, so the schema does the heavy lifting. The description's '{studentId}' merely restates the schema field and adds no format, lookup, or validation guidance beyond it.

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 specific resource (contacts authorized to pick up a student) and scopes it to one student, which implicitly distinguishes it from the broader jackrabbit_list_contacts and from jackrabbit_get_contact. It is a noun phrase rather than a verb phrase, but an agent can still tell what it returns.

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?

Usage is only implied by the resource name: call it when you need the pickup-authorization list for a known student. There is no explicit when-to-use, no exclusions, and no mention of siblings like jackrabbit_list_contacts or jackrabbit_get_contact, so the agent must infer the boundary.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value by disclosing the shape of the returned payload (schedule, room, openings, waitlist counts, tuition, flags) and the underlying endpoint, but says nothing about pagination behavior or the default active-only scoping that the archived parameter 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?

One front-loaded sentence that names the resource first and then the payload, followed by the endpoint. The field enumeration is long but each item is informative; nothing is wasted or repeated.

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 carries the burden of describing return values, and it does so thoroughly by listing the fields present on each class. Combined with a fully documented 8-parameter schema and clear read-only annotations, an agent has enough to call this correctly; only cross-tool routing guidance is missing.

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 every parameter is documented inline, including defaults, ranges, and the next_page pagination hint. The description adds no parameter-level meaning beyond the field list, which is the expected baseline when the schema does all the work.

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 verb and resource ('List classes') and then enumerates exactly what each class record carries, so an agent knows this returns full class detail rather than just listings. It does not distinguish itself from siblings like jackrabbit_get_class (single class) or jackrabbit_list_class_listings, which is the only thing keeping it from a 5.

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 use this versus jackrabbit_get_class or jackrabbit_list_class_listings, nor any mention of common filter workflows (e.g., 'use student_id to get a student's schedule'). The schema's eight filters are never referenced in prose, so the agent must infer their purpose entirely from field descriptions.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context by naming the returned fields and the underlying GET /v1/ClassListings endpoint, but says nothing about pagination, auth requirements, or how include_closed interacts with organization settings beyond what the schema states.

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 front-loads the resource and its contents, then the filters, then the endpoint. No wasted clauses, though the long comma-separated run makes it slightly harder to scan than a split sentence would.

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 13 optional params, no output schema and no nested objects, the description compensates well by listing the fields the listing returns (openings, age ranges, tuition, address, registration links). The missing piece is routing versus jackrabbit_list_classes and any pagination note, but overall it is sufficient to call 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 the schema already documents all 13 parameters including pagination and include_closed. The description's filter list roughly mirrors the schema parameters (category, instructor, days, session, location, gender, room, status) without adding format, id-lookup, or combination semantics, 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?

States a specific resource (public-facing class schedule/class listings) and enumerates the fields returned plus the filterable dimensions, so an agent knows what it gets. It does not, however, distinguish itself from the sibling jackrabbit_list_classes, which an agent could easily confuse it with.

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?

The phrase 'public-facing ... with openings' hints at the scenario, but there is no explicit when-to-use, when-not-to-use, or pointer to jackrabbit_list_classes as the alternative for internal/all-class data. Usage must be inferred entirely.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that results carry opt-out and primary/billing/pickup flags and the backing endpoint, but says nothing about pagination behavior or result size limits beyond what the schema already documents.

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 enumerating the return fields plus the endpoint path — efficient and scannable. The field list is dense but each item conveys real information about the payload.

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 11 optional filters, the enumeration of returned fields (name, type, email, phones, address, flags, opt-outs) is genuinely necessary and present. What is missing is sibling disambiguation and any note on pagination/incremental sync usage, which the schema alone covers only partially.

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% with 11 parameters, so the baseline is 3. The prose only mentions the 'authorized-for-pickup' flag and does not explain the filtering dimensions (email, phone, updated_since, family_id/member_id) or how they combine, adding little beyond the schema.

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?

Specific verb (List) plus resource (family contacts / GET /v1/Contacts) with an enumerated set of returned fields, so the agent knows exactly what data comes back. It does not, however, distinguish itself from the closely-related jackrabbit_list_authorized_contacts or jackrabbit_get_contact 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?

Usage is only implied by the word 'List' and the 'family contacts' scope; there is no explicit statement of when to pick this over jackrabbit_list_authorized_contacts (which is essentially the authorized=true subset) or jackrabbit_get_contact for a single record. An agent must infer the choice from sibling names alone.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: the underlying endpoints (GET /v1/Enrollments vs /v1/Enrollments/future), the fact that dropped enrollments are included in scope, and the field-level shape of a record (drop date/reason, transfer target).

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?

Three clauses, front-loaded with what is listed and what is returned, followed by filter semantics and the endpoint. Dense but every clause carries information; the endpoint parenthetical is the only mildly expendable part.

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 compensates by naming the record fields an agent gets back, and annotations cover the read-only profile. Pagination behavior is the notable remaining gap for a nine-parameter list tool (the schema mentions next_page, but the description does not reinforce it).

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 all nine parameters are already documented; the baseline of 3 applies. The description does add one genuinely new detail the schema lacks — that omitting "enrolled" means no status filter — but it says nothing about the id-based filters (class_id, student_id, family_id, location ids) or pagination.

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 verb and resource ("List enrollments") and parenthetically defines the domain object ("a student in a class"), then enumerates the returned fields. It never names the sibling it competes with (jackrabbit_get_enrollment for a single record), so sibling differentiation is only implicit in the verb.

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?

The description explains filter behavior ("enrolled=true returns only existing enrollments... omit it for no status filter"; "future=true lists enrollments that start later"), which implies when to use the tool but never states use-when/use-instead-of guidance. An agent must infer that jackrabbit_get_enrollment or jackrabbit_get_class_roster are the alternatives for single-record or roster-shaped needs.

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, destructivHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned field set, which is genuine value, but says nothing about pagination behavior, total counts, or whether archived families are included — the most consequential ambiguity for a list endpoint.

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: the first front-loads purpose and the returned field inventory, the second covers filtering and the endpoint path. Dense but no filler; the field enumeration is long yet arguably earns its place given there is no output schema.

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, describing the returned fields is exactly the right compensation, and annotations cover safety. The remaining gap is whether archived/soft-deleted families appear in results and how pagination interacts with a total count, which matters for a list endpoint with 7 optional filters.

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 the schema already documents all seven parameters including cross-references to jackrabbit_list_options for status_id and location_id. The description's filter list mirrors the schema without adding format, matching semantics, or interaction rules (e.g., whether filters AND together). 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?

States a specific verb and resource ('List family accounts (billing households)'), clarifies the business meaning of 'family' as a billing household, and enumerates what comes back. It doesn't distinguish itself from siblings like jackrabbit_get_family or jackrabbit_list_archived_families, but an agent can tell broadly what it does.

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?

The filter enumeration ('Filter by status, location, name, phone or last update') implies when to reach for this tool, but there is no explicit guidance on when to prefer it over jackrabbit_list_archived_families or to fetch a single record via jackrabbit_get_family. Usage is inferable but not stated.

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 and destructiveHint=false, so safety is covered; the description adds the workflow role (feed ids into other tools) and the shape of returned records. It also exposes the backing endpoint GET /v1/Options/{list}, which is useful for debugging but doesn't add rate-limit or caching 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?

Purpose is front-loaded in the first clause, followed by the usage hint and endpoint. The long middle enumeration is bulky and largely redundant with the enum, but it is one tight sentence with no filler.

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?

There is no output schema, and the description compensates by naming the returned fields (id, value, description). Combined with the read-only annotations and a self-contained enum parameter, an agent has everything needed to call this 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 coverage is 100% and the single parameter is a 28-value enum, so the schema already carries the semantics. The prose enumeration partially duplicates it and is actually incomplete (employment_types, tshirt_sizes, uniform_sizes, leotard_sizes, martial_arts_belt_sizes, policy_groups are missing), so it adds little beyond a rough conceptual grouping.

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 verb and resource ('allowed values ... of one dropdown list') and names the exact return fields (id, value, description). The enumeration of list families makes it immediately distinguishable from the sibling read tools that consume these ids.

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?

'Use the ids as filters on the other tools' explicitly positions this as a prerequisite lookup for the list/get/roster tools. It gives clear context for when to call it, though it doesn't state exclusions (e.g., that it is not needed when ids are already known).

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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds the returned field inventory, which is genuinely useful in the absence of an output schema, but says nothing about pagination behavior, result ordering, or default volume.

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 tight sentences: purpose first, then the field inventory, then the endpoint. Every clause carries information and nothing is padded, though the trailing raw path is of limited value to an agent.

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 enumerated return fields are the main thing the description must supply, and it does. Pagination and filters are fully documented in the schema and safety is covered by annotations, leaving only minor gaps like ordering and maximum page semantics.

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% and every parameter already carries a precise description (page, class_id, is_active, last_name, page_size, created_date). The description adds no filtering semantics beyond what the schema provides, 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?

States a specific verb and resource ('List staff and instructors') and enumerates the fields returned, so the agent knows this is a bulk retrieval of staff records. It does not explicitly contrast with the sibling jackrabbit_get_staff_member, so it stops short of a 5.

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 vs alternatives such as jackrabbit_get_staff_member (single record) or jackrabbit_list_contacts. The endpoint path implies a filtered list, but the agent must infer that on its own.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description's real added value is disclosing the payload contents — including sensitive health notes (medications, allergies, special needs, doctor) — which warns the agent it will receive PHI-like data. It does not mention pagination behavior, result ordering, or rate limits, so it adds only moderate context beyond the annotations.

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 dense sentences plus an endpoint reference, with the resource and returned data front-loaded and the filter surface second. Every clause maps to concrete information; only the trailing endpoint is arguably redundant.

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 compensates by enumerating the returned fields, which is exactly what an agent needs to judge whether this call answers its question. Combined with the fully documented input schema and read-only annotations, only pagination/ordering expectations remain unstated — a minor gap for an 11-parameter list 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%, with all 11 parameters individually documented (page, page_size, date formats, is_active semantics), so the schema carries the burden. The description's filter list covers only 5 of the 11 parameters and omits page/page_size/created_date/updated_since/date_last_inactive, adding no format or interaction detail beyond the schema; 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 opens with a specific verb and resource ('List students') and then enumerates the returned fields and the filter surface, plus the backing endpoint GET /v1/Students. It is clearly a bulk-list tool, which distinguishes it implicitly from the singular jackrabbit_get_student, though it never names that sibling outright.

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?

'Filter by family, active status, location, last name or dates' signals the intended usage contexts, so an agent can infer this is the tool for filtered browsing of students. However, there is no explicit statement of when to prefer jackrabbit_get_student for a single record, or when to fall back to jackrabbit_list_families/contacts, leaving the routing to inference.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the underlying endpoint and the returned field set, but discloses nothing about ordering, rate limits, or what an empty result means. Some added value, but not rich behavioral context.

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 compact sentences plus the endpoint path, with the resource and returned fields front-loaded. Every element is relevant, though the trailing GET path is marginal value for an agent.

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 simple read-only list tool with full schema coverage and safety annotations, the description is largely sufficient, and it usefully enumerates returned fields in the absence of an output schema. Ordering/empty-result semantics are the only notable omissions.

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?

The description restates the three filter dimensions that already exist in the schema (class_id, student_id, entry_date) without adding syntax or behavior detail. Pagination parameters are not mentioned in the description, but the schema covers all five params at 100% coverage, 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?

States a specific verb (List) and resource (class waitlist entries) and enumerates the fields returned (class, student, entry date, position, notes). It is distinguishable from the sibling jackrabbit_create_waitlist_entry by its read-only listing nature, though the write counterpart is never named explicitly.

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?

Filtering options (class, student, or entry date) are stated, which implies usage for narrowing a waitlist, but there is no explicit when-to-use guidance, no mention of when a different listing tool (e.g. get_class_roster or list_classes) is preferable, and no prerequisites.

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