edookit-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
Many tools are module-prefixed, but several clusters are hard to distinguish: lessons_list, attendance_daily_schedule, direct_attendance_lessons, and changed_timetable all serve timetable-ish purposes. payments_types and payments_categories are nearly indistinguishable from their descriptions, and person_search, student_personal_data, and attendance_students overlap around person data.
Naming Consistency3/5
Snake_case and module prefixes are reasonably consistent, but verb usage is not: read endpoints appear as bare nouns (attendance_students), list_* (lessons_list), and *_by_date (attendance_passages_by_date). Create operations mix insert_ and create_, and a few tools like person_search and changed_timetable break the module_prefix pattern.
Tool Count2/5
At 46 tools, this is far above the 25-tool threshold and will be difficult for agents to navigate efficiently. The breadth is partly justified by multiple modules, but many tools are trivial version or reference-data endpoints that could be consolidated or removed.
Completeness3/5
Payments has solid CRUD coverage, and attendance includes reading, inserting, and excuse workflows. However, attendance passages and attendance records are insert/read-only with no update/delete, and lessons, courses, evaluations, and individual goals are mostly read-only or single-purpose, leaving notable lifecycle gaps.
Average 3.4/5 across 46 of 46 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates that a payment transaction is recorded and does not mention side effects, validation rules, defaults, idempotency, or permission requirements. This gives the agent no meaningful behavioral context beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the brevity is under-specification rather than effective conciseness. There is no front-loaded useful information because there is almost no information at all. For a tool with 14 parameters, this single phrase does not earn its place as a sufficient definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity signaled by 14 parameters, 4 required fields, no output schema, and no annotations, the description is severely incomplete. It gives the agent no help with required fields, defaults, parameter relationships, or expected behavior. This is not enough for an agent to invoke the tool correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 36%, with 14 parameters and 4 required, but the description adds no parameter information whatsoever. Fields like amount, currency_id, organization_id, message, and bank_account_number remain semantically opaque in both the schema and description. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Record') and resource ('a payment transaction'), so an agent can discern the basic operation. It does not explicitly differentiate from payments_update_payment or payments_delete_payment, but the verb does convey creation well enough for basic purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus sibling tools like payments_update_payment or payments_delete_payment. No prerequisites are mentioned, such as the need for an existing organization, currency, or payment type. The agent must infer usage entirely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a mutation ('Update') but does not state whether the update is partial or full, which permissions are needed, whether changes are irreversible, or what happens to omitted fields. This is a significant transparency gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no wasted words. However, it is under-specified for a tool with 13 parameters and no other context, so its brevity borders on inadequacy rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, 13 parameters, and 0% schema description coverage, this one-line description is far from complete. It omits required-field semantics, update behavior, return value, and any guidance on how parameters interact. The agent has almost nothing to work with beyond the schema's bare names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions none of the 13 parameters. It adds no meaning beyond the raw input schema, leaving the agent to guess what each of the various properties represents or how they relate to updating a payment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Update an existing payment record.' It distinguishes itself from payments_create_payment by emphasizing 'existing,' and from unrelated siblings. It lacks explicit mention of which fields can be changed, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like payments_create_payment, payments_delete_payment, or payments_update_prescription. The word 'existing' implies it is not for creating new records, but no explicit usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It only states that an update occurs; it does not reveal whether fields are partially or fully replaced, whether state transitions are validated, whether updates are reversible, or what permissions/effects are involved. For a mutating tool with 13 parameters, this is insufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler, and the verb-object structure is front-loaded. It is efficient in length, though the minimization comes at the cost of substantive details already penalized elsewhere. Structure is clean and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update operation with 13 parameters, no annotations, and no output schema, this description is far too thin to support correct invocation. An agent would not know what fields are updatable, what constraints apply, what the response looks like, or how this relates to create/delete flows. Substantial context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 15%, and the description adds no parameter-specific meaning beyond the schema. With 13 parameters and most left undocumented, the description needed to compensate by explaining key fields such as state, amount, direction, person_list, or related prescription IDs. It does none of this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('payment prescription'), and 'existing' clarifies it targets already-created prescriptions. This distinguishes it from payments_create_prescription and payments_delete_prescription, and the resource term separates it from payments_update_payment. It does not, however, articulate any additional scope or field-level intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided, and no alternative tool is named. The word 'existing' weakly implies this tool is for modifying a prescription that has already been created, but there is no discussion of when update is appropriate versus create or delete. This is at best implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only says 'Submit', indicating a write operation, but gives no information about side effects, whether an existing excuse is replaced, whether the submission is reversible, or what response/confirmation the caller can expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no redundant wording. It is easy to parse, though the brevity comes at the cost of missing behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and incomplete parameter coverage. The description does not explain the 'avízo' concept, what happens after submission, how to handle duplicate future excuses, or any constraints such as lead time or permission requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 'excuse' has a schema description, so coverage is 33%, and the description does not compensate. It mentions 'a student' and 'a specific lesson', which weakly maps to student_id and lesson_id, but it adds no detail about where those IDs come from or what format they must follow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Submit') and names both the resource ('future absence notice') and the target ('for a specific lesson'). It clearly differentiates from the sibling direct_attendance_current_excuse by emphasizing 'future'. However, the relationship to direct_attendance_record or the broader attendance workflow is not clarified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'future absence notice' implies the tool is for upcoming absences, and 'for a specific lesson' narrows the context. But it does not explicitly state when to use this tool instead of direct_attendance_current_excuse or direct_attendance_record, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It communicates that this is an insert/mutation operation, but it does not mention possible side effects, duplicate handling, permissions, default behavior beyond what the schema already covers, or what happens after a successful insert.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that immediately states the action and target. There is no filler, and the core purpose is front-loaded. For a simple insert tool, this is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, no annotations, and no output schema, so the description needs to supply more operational context. It omits return behavior, duplicate-record behavior, status-category semantics, and when to prefer sibling tools, leaving the agent without enough information to confidently invoke it in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%, with status, minutes_late, and minutes_early already described in the schema. The description adds only broad context about a student and a lesson, which is marginal beyond the parameter names. It does not meaningfully explain the undocumented student_id and lesson_id semantics, so it fails to fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Insert') and names the resource ('attendance record') with the target context ('for a student in a lesson'). It is clear about what the tool does, though it does not explicitly call out how it differs from sibling tools like attendance_insert_passage or direct_attendance_future_excuse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as direct_attendance_future_excuse, direct_attendance_current_excuse, or attendance_insert_passage. The description states the action but provides no context for selection, no exclusions, and no conditions of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It signals destructive intent with 'Delete' and 'remove', but it does not disclose that deleting the prescription also removes all persons and payments, nor does it mention irreversibility or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the primary action and states the secondary mode efficiently, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, dual-mode tool with no annotations and no output schema, this definition is too thin. It omits side effects, sibling differentiation, and operational context, leaving the agent to infer important safety and routing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: each parameter has a meaningful description, including the important note that delete_prescription 'deletes the entire prescription with all persons and payments'. The tool description adds no parameter-level detail, but the schema already covers that burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('payment prescription') and both supported actions ('Delete' / 'remove persons'), so an agent can tell what the tool does. It does not explicitly distinguish it from siblings such as payments_delete_payment or payments_update_prescription, so it falls just 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus related tools like payments_delete_payment or payments_update_prescription. The dual mode is implied by the wording, but there is no decision rule, prerequisite, or alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that an excuse is submitted, implying a write operation, but it does not disclose whether the excuse replaces an existing one, what permissions are needed, how the system responds, or any side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler or repetition. It front-loads the action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with no annotations, no output schema, and only 33% schema parameter coverage, the description is too thin. It lacks guidance on tool selection, operational side effects, expected output, and parameter details, making it incomplete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only 'excuse' documented as 'Excuse reason.' The description adds minimal semantic value by mapping the tool to a student's lesson absence, which hints at student_id and lesson_id, but it does not explain how to obtain or format these IDs or any constraints on the excuse text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Submit a current excuse... for a student's lesson absence.' The word 'current' helps differentiate it from the sibling tool direct_attendance_future_excuse, though it does not name that tool directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for submitting an excuse for an existing/current absence rather than a future one, but it does not explicitly state when to use this tool versus alternatives like direct_attendance_future_excuse. The usage context is only implied by the word 'current.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, but it only restates the main function. It does not disclose whether the optional pk filters a returned list, whether omitting it returns all periods, or what the response shape is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that immediately states the action and resource. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no output schema, no annotations), and the description captures the core return concept of time ranges. However, it leaves the pk filtering behavior and response format to inference, so it is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and 'pk' is already documented as 'Optional period ID', so the baseline is 3. The description adds no parameter-level detail beyond the bell-schedule context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get') and resource ('teaching period time ranges / bell schedule'), making the core function clear. It is distinct from nearby schedule tools like attendance_daily_schedule, though it does not explicitly name or contrast siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided beyond the bare statement of purpose. The description does not mention alternatives, prerequisites, or contexts where another schedule tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. 'Get' implies a read operation, but the description does not state that it is read-only, nor does it explain behaviors around validity ranges, date filtering, authorization requirements, or response size. This is acceptable for a simple read, but it lacks the explicit transparency expected when annotations are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and resource and then adds relevant specifics. Every word contributes meaningful information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read operation with three optional, well-documented parameters and no output schema. The description names the core returned content, but it does not clarify the response format, pagination, or the effect of omitting student_id, even though the schema partly covers this. It is adequate but has clear gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the input schema, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema; it mentions 'validity ranges' as output content, not as a filter explanation. Thus the description does not need to compensate, but it also does not add extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and names a concrete resource ('student learning agreements'), further specifying the included content: coach feedback, subcompetences, and validity ranges. It is clearly distinguishable from the sibling 'individual_goals_lesson_content' by the resource type, though it does not explicitly contrast itself with that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, prerequisites, or exclusions are provided. The description implies this tool is for retrieving learning agreements, but it does not help an agent decide between this and the related sibling tool or indicate when the optional parameters should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, but it only says 'Get' and does not disclose return shape, filtering behavior, or side effects. It does not contradict any annotations since none exist, but it reveals very little about how the tool behaves beyond being a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The main action is front-loaded, and the critical invocation constraint follows immediately. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description should compensate with behavioral and return-value context. It does not explain what the individual lesson content looks like, how results are scoped, or what the response contains. The schema handles parameter definitions, but the overall tool context remains thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful value by declaring the at-least-one-required rule among student_id, lesson_id, and date_from, which is not expressed as required in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Get individual lesson content for students.' It is more specific than a tautology and gives a sense of scope, though it does not explicitly distinguish itself from sibling tools like individual_goals_learning_agreements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an invocation constraint—'At least one of student_id, lesson_id, or date_from is required'—but gives no guidance on when to choose this tool over alternative tools. It also omits the schema's restriction that lesson_id cannot combine with date_from/date_to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It communicates that deletion occurs, but does not state whether the deletion is permanent, reversible, cascading, or requires specific permissions. For a destructive operation, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, one short sentence with no filler. While this is efficient, it provides only the bare minimum of value beyond the tool name, so it is not a fully robust description despite its compactness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation with no annotations and no output schema, the description is incomplete. It does not mention consequences of deletion, return behavior, or any necessary safeguards. Given the simplicity of the single-parameter schema, more context about the deletion's impact was expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter is `id`, described as 'Payment ID.' The description adds no additional parameter meaning, but the schema already provides sufficient semantic information, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete a payment record.' This clearly distinguishes the tool from sibling operations like payments_create_payment, payments_update_payment, and payments_delete_prescription, which involve different actions or resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance about when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or that updates should be preferred over deletion in certain contexts, so the agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It conveys a read operation and point-in-time semantics, but does not mention pagination, scope of returned data, privacy/permissions, or what 'personal data' includes. No side effects or response characteristics are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action and resource immediately and the temporal constraint concisely, which is appropriate for a simple read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and no output schema, the description and schema are minimally sufficient for basic invocation. However, the lack of annotations, output details, and guidance on choosing between this and sibling tools leaves meaningful gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already well-documented in the input schema. The description adds no meaningful parameter semantics beyond what the schema provides, which is acceptable but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get') and resource ('personal data of students') with a useful time qualifier. It is distinguishable enough from siblings like employee_personal_data and student_statistics, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like person_search, employee_personal_data, or student_statistics. The reference-date qualifier implies a point-in-time use case, but there are no explicit use cases, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool gets but does not mention that it is read-only, whether authentication is required, what fields are included beyond school year and semester, or any potential error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that directly states the purpose and a key detail. Every word earns its place; there is no redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with no annotations and no output schema, the description gives the essential purpose but omits a full account of what settings are returned. It is minimally viable but could be more complete by listing all setting fields or stating that only the school year and semester are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds context about the return value (school year and semester), which is not conveyed by the schema, although no parameter explanations are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'attendance service settings', with a concrete example of its content ('current school year and semester'). This distinguishes it from sibling tools like attendance_version or attendance_classes, though it does not explicitly exclude alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus any alternative. There are no preconditions, no mentions of related tools, and no indication of scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'Get ... version,' which implies a read operation but discloses nothing about the response format, whether it returns a bare string or extended metadata, or whether any state affects the result. For a simple probe the gap is modest, but the description adds zero behavioral context beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single seven-word sentence that front-loads the verb and resource with zero filler and no repetition of the tool name. Every word earns its place; the brevity is appropriate for a zero-parameter version probe.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Invocation is trivially simple with no parameters, but there is no output schema and no annotations, making the description the only information source. An agent knows what the tool does yet must guess at the response shape and has no guidance on when to prefer it over the other version tools. Adequate for a minimal tool, but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so there is nothing for the description to document. Per the baseline for 0-parameter tools, the description need not explain arguments, and the single sentence correctly implies an argument-free invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a specific resource ('Lessons (Hodiny) module API version'), making the tool's function clear. It follows an identifiable version-tool pattern seen among siblings (attendance_version, payments_version, courses_version) and is easily distinguished from functional siblings like lessons_list or lessons_rooms. Minor ambiguity remains about whether 'version' refers to the API version or module version, but the intent is essentially unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the parallel version probes (attendance_version, payments_version, courses_version) or when a version check is appropriate. The description provides no context, exclusions, or selection criteria, leaving the agent to infer that this is the Lessons-module version probe from naming conventions alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a create operation but does not explain side effects, required amount/currency relationships, default values like state=1 or direction=1, or what happens if per-person amounts partially cover the required fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste. It states the core action and the key optional capability compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, no annotations, and no output schema, a one-sentence description is insufficient. It omits important context such as required amount unless per-person amounts are set, default states and directions, and expected behavior or return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 58%, so the schema handles most parameter meanings. The description adds value by explaining that per-person amount overrides are supported, which clarifies the optional amount field. However, it does not help with undocumented parameters like is_credit, category_id, specific_symbol, or previous_prescription_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a new payment prescription', which clearly distinguishes it from sibling tools like payments_create_payment, payments_update_prescription, and payments_delete_prescription. The per-person amount override detail adds useful scoping beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives such as payments_create_payment or payments_update_prescription. It does not mention prerequisites, conditions for creation, or when per-person overrides are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately conveys that this is a read-only listing operation and includes guardian data, which is useful. However, with no annotations, it does not disclose response format, pagination behavior, or the sensitive nature of legal guardian data, leaving some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no filler. The main action and scope are front-loaded, and the optional filter is clearly stated at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core invocation facts: list all students, include guardian data, and optionally filter by ID. But it lacks output details, pagination information, and any clarification about how this relates to overlapping sibling tools, so it is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes pk as an optional student ID with 100% coverage, and the description mostly repeats this by saying 'optionally filtered by student ID.' It adds little semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: 'List all students including legal guardian data, optionally filtered by student ID.' It is easy to understand the tool's core purpose, but it does not explicitly distinguish itself from similar sibling tools like student_personal_data or direct_attendance_student_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as student_personal_data or person_search. It only mentions the optional student ID filter, but does not explain scenarios, exclusions, or conditions that would make this tool the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of indicating that this is a read operation, which 'Get' conveys. It adds student/day scoping but does not describe output shape, limits, or behavior on missing data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler. The verb, object, and key scoping are front-loaded, and every word contributes to conveying purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter retrieval tool this is mostly adequate, but there is no output schema and no explanation of what the 'lesson overview' includes. The lack of distinction from sibling tools, especially direct_attendance_student_overview, leaves some contextual ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters are already documented clearly, including the date default. The description adds no additional parameter-level meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('lesson overview'), scoped to a student and a given day. It does not explicitly distinguish itself from sibling tools like direct_attendance_student_overview, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the many attendance-related siblings. It states the tool's action but gives no alternatives, exclusions, or conditions for preference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It identifies the operation as a 'Get' but does not disclose the response format, whether any side effects occur, or what 'API version' will be returned. The behavior is only slightly clarified by the tool name and description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the action and resource. There is no wasted text or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter version-check operation, the description is nearly complete: an agent knows what action to take and on which module. It could be enhanced by noting the expected response format, but the absence of parameters and the simple nature of the tool reduce the need for more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics for the description to clarify. The description appropriately reflects this no-input design by making no parameter claims.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Get' and the resource 'Payments (Platby) module API version', making the tool's purpose immediately clear. It also naturally fits the pattern of sibling version tools such as attendance_version, lessons_version, and courses_version, so an agent can infer the module being queried even without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternative version tools or other payment-related tools. It simply states what the tool does without explaining the expected context, such as needing to verify API compatibility before making other calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden; the verb 'List' implies a non-mutating read, which is useful. However, it does not disclose what happens when pk is supplied (filtering) versus omitted (full list), nor any ordering, pagination, or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single seven-word sentence that front-loads the action and resource with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description plus the 100%-covered schema are largely sufficient: the agent knows what is listed, for whom, and that pk optionally targets one classification. The main residual gap is routing versus sibling tools, which belongs to usage guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (pk is documented as 'Optional classification ID'), so the baseline of 3 applies even though the description itself does not mention the parameter. The schema already provides the needed meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('job classifications'), and the parenthetical '(work categories) for staff' clarifies scope and distinguishes it from the sibling attendance_classes. However, the differentiation is implicit rather than explicit and no sibling is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as attendance_classes or attendance_staff. There are no exclusions, prerequisites, or routing cues to help an agent pick among the many attendance_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It provides meaningful behavior beyond the schema by explaining the positive/negative ID convention. However, it does not disclose output shape, pagination, or behavior when pk is omitted, which leaves some ambiguity for a no-output-schema tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action is front-loaded, and the critical ID-sign behavior follows immediately. Every word contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter list tool, the description covers the main action and the non-obvious ID convention. But with no output schema and no annotations, it would benefit from stating what the returned objects contain or what happens with no pk. The absence of any sibling guidance also leaves the tool somewhat underspecified in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents pk as 'Optional group/course ID' with 100% coverage. The description adds genuine value by specifying that a positive pk selects a schedule group and a negative pk selects a course, which is not derivable from the schema. This makes the parameter semantics clearer and more actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the resource ('schedule groups and courses'). It also communicates a useful disambiguation rule (positive ID = schedule group, negative = course), which helps distinguish this tool from related attendance reference tools. However, it does not explicitly differentiate itself from nearby siblings like attendance_classes or attendance_students.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternative attendance or course-related tools. It only states what the tool lists and how the ID sign maps to entity type. There are no explicit conditions, exclusions, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of revealing behavior. The verb 'List' clearly signals a read-only operation, which rules out mutation, but no additional behavioral traits such as ordering, filtering, localization, or inactive-item visibility are disclosed. For a zero-parameter read-only tool, this is minimal but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler or redundant detail. It front-loads the action and resource, making it an appropriately minimal definition for a simple list endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is enough to invoke a parameterless list endpoint, but it does not clarify what payment categories represent or how they relate to payments_types or payment creation tools. With no output schema, the return values are only vaguely specified as 'categories,' leaving the agent to guess at the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, and schema description coverage is 100% because there is nothing to document. The description adds no parameter-level meaning, but none is needed; a baseline 4 applies for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear imperative verb and resource: 'List' + 'payment categories.' It does not, however, distinguish categories from the sibling payments_types tool, which could plausibly refer to an overlapping resource, 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.
Usage Guidelines2/5
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 tool versus alternatives such as payments_types or other payment reference list tools. The only hint is the tool name and resource, leaving the agent to infer its intended role in the payment workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility; 'List' does imply a read-only, non-destructive operation, which is a positive signal. However, it does not disclose any additional behavior such as output shape, ordering, permissions, or whether only active types are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words, so it is maximally concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool this is minimally usable, but it lacks an output schema or any description of the returned payment-type values. Sibling-tool context suggests a larger payments API, and without behavioral or return details the description is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100% (trivially). With zero parameters, the baseline is 4; no parameter documentation is needed, and the description cannot add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and a distinct resource ('payment types'), clearly separating it from sibling tools like payments_categories, payments_currencies, and payments_bank_accounts. It does not elaborate on what a payment type is, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool instead of the many payment-related siblings such as payments_categories or payments_list_prescriptions. There is no mention of context, exclusions, or relationships to other tools, so the agent must infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. 'Search' and 'Returns' imply a read-only lookup, and the description adds output details like roles, children, and representatives. However, it does not explicitly state permissions, not-found behavior, or possibility of multiple results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with no filler. It states the action, identifiers, and return summary efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter search tool with no output schema, the description adequately explains input format and returned data categories. Missing details like empty-result behavior or authentication are minor gaps for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the schema already documents searchCriterion with format examples. The description only restates 'Edookit ID or Plus4U ID' without adding new semantic meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches for a person by specific identifiers (Edookit ID or Plus4U ID) and returns person data with roles, children, and representatives. This is a clear verb+resource, but it does not explicitly contrast with sibling tools like student_personal_data or employee_personal_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of when a person lookup is needed, when a more specific student/employee lookup should be preferred, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does disclose the success outcome ('Returns HTTP 201 on success'), which is useful for a creation endpoint, but it does not mention error behavior, permissions, duplicate handling, or any other side effects beyond creating a record.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The main purpose is front-loaded and the success response is stated efficiently. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and no output schema, the description is minimal but workable because the schema covers parameters well. However, it lacks broader context about how passage events relate to attendance records, what validation applies, or what the caller should do with the 201 response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents every parameter. The description adds no additional parameter-level meaning, which is acceptable under the baseline but not above it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the action ('Record'), the resource ('a new access passage event'), and adds domain context ('RFID entry/exit'). This differentiates it from read-oriented siblings like attendance_passages_by_date and attendance_passage_by_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as attendance_passage_by_id or direct_attendance_record. There are no prerequisites, exclusions, or hints about typical workflows involving passage events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does communicate the core behavior — retrieving the Courses module's API version — which is a safe, read-only informational operation. However, it does not disclose the response format, whether authentication is required, or error/failure behavior, which are clear gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero waste. 'Get Courses (Kurzy) module API version.' communicates the module identity and the operation efficiently, and the size is appropriately matched to the trivial complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema, no-annotation tool, the description is nearly complete: it tells an agent which module's version this is and what operation it performs. The only missing context is what the caller should do with the version value and what the return payload looks like, but given the tool's minimal complexity, these are minor omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The empty input schema is fully consistent with the description, which implies a call with no arguments. There is nothing for the description to add, and none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a specific resource ('Courses (Kurzy) module API version'), and the parenthetical '(Kurzy)' plus module naming disambiguates it from sibling version tools like attendance_version, lessons_version, and payments_version. It is clear, though it relies on naming rather than an explicit contrast with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this tool versus the sibling *_version tools, no mention of what the version is useful for (e.g., compatibility checks or verifying API availability), and no exclusions or prerequisites. With four module version tools among the siblings, an agent must infer the selection rule from the module name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only retrieval action ('Get') and enumerates the returned data categories, which is helpful. However, there are no annotations and no mention of response shape, date-range semantics, or how 'full history' interacts with the optional date_from/date_to parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that names the action, target, and included data without filler. Every word contributes to understanding what the tool returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the description gives the core idea and output components, but the absence of annotations and output schema leaves gaps around response format, optional date filtering, and when to prefer this over related attendance siblings. It is adequate but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents date_from/date_to reasonably well, and student_id is self-evident from the tool name and description. The description itself adds no parameter-specific meaning beyond implying the student context, so it neither compensates for the undocumented student_id nor clarifies how the optional dates scope the 'full' history.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get a student's full attendance history' with explicit contents (statuses, notes, excuses, absence advices). This clearly distinguishes it from sibling tools like attendance_students, direct_attendance_record, or attendance_passages_by_date, which serve different attendance-related purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the many attendance/direct_attendance siblings. It does not state exclusions, prerequisites, or alternative tools for narrower queries such as a single date, lesson, or excuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does communicate that this is a read operation scoped to a point in time ('as of a reference date'), which is useful. However, it does not disclose whether inactive employees are included by default, what fields are considered 'personal data', or any authorization/scope boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the core meaning, and the most important qualifier ('as of a reference date') is positioned clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple two-optional-parameter retrieval tool, but gaps remain: there is no output schema, so the return shape is unspecified, and the description does not mention the include_inactive_since behavior beyond what the schema already states. The employee-versus-student distinction helps with sibling differentiation, but the overall context is somewhat thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the structured schema already documents both parameters clearly. The description adds only marginal meaning by calling 'date' the 'reference date,' which is consistent with the schema but does not explain the interaction between date and include_inactive_since.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('personal data of employees'), and the reference-date qualifier adds meaningful scope. It clearly distinguishes itself from sibling tools like student_personal_data and person_search by identifying both the data type and subject population.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as person_search or student_personal_data. The description implies a date-based employee data lookup, but it never states exclusions, prerequisites, or which sibling tools are more appropriate for other lookup scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the behavioral disclosure burden. It usefully states the return content (actual vs scheduled state per lesson) and 'optional filters,' but it does not mention date requirement, pagination, ordering, or error handling. This is partial but not comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded with the core action and resource, followed by the key return characteristic. Every clause adds value; no redundant or promotional language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with no output schema and no annotations, the description is adequate but thin. It states the return type (actual and scheduled state per lesson) and date scope, but does not specify whether date is effectively required (the schema marks all params optional), nor any response envelope or pagination behavior. This leaves some ambiguity for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all 8 parameters with 100% coverage, so the baseline applies. The description only adds 'optional filters,' which does not add meaning beyond the schema's per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a well-defined resource ('lessons (timetable) for a given day'), and further distinguishes itself from siblings like changed_timetable by stating it returns both actual (with substitutions) and scheduled state per lesson. The scope is immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over siblings such as changed_timetable or direct_attendance_lessons. There are no explicit conditions, exclusions, or alternative routing, so the agent must infer usage from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It conveys a read-only listing operation and the 'all' qualifier indicates no filtering, but it does not describe the returned values, ordering, or any other behavioral traits beyond the basic list action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant information. It is immediately readable and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter reference list tool, the description is nearly complete: an agent knows what to call and what it will get. It could be slightly richer by stating what each returned work/activity type entry contains, but the lack of an output schema makes this a minor gap rather than a blocking issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed; the word 'all' reinforces that the tool returns the full set without requiring input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'List,' and a clear resource, 'all work/activity types.' It is understandable and distinct enough from sibling list tools like lessons_course_types, though it does not explicitly distinguish itself from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as lessons_list, lessons_course_types, or attendance_classes. With zero parameters and a simple enumeration purpose, usage context is implied but never stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'List' clearly implies a read-only operation, but the description does not disclose response format, ordering, or whether the currencies are payment-specific. For a parameterless list tool this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundant information. It is appropriately concise for a simple list endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides the essential selection information: this tool lists available currencies. It would benefit from clarifying what a currency entry contains, but the low complexity and lack of required arguments make the description largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is effectively 100%, so there are no parameter details for the description to add. The baseline score of 4 for a zero-parameter tool applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('currencies available in Edookit'), making the basic purpose clear. It does not explicitly differentiate from sibling tools, though no sibling appears to target currencies, so the risk of confusion is low.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives. It does not mention payment contexts, exclusions, or more specific sibling tools such as payments_categories or payments_types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only states 'List payment prescriptions with optional filters' and does not describe what the response contains, whether results are paginated or ordered, how filters interact, or any read-only guarantees. 'List' implies read-only behavior, but the effect is not truly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with the operation front-loaded and no filler. It is appropriately sized given that the schema handles the parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with complete parameter descriptions, this is minimally viable. However, with no output schema and no annotations, it leaves the agent to infer the response shape and possible pagination or scoping behavior, which is a clear gap for a tool that presumably returns a collection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all 8 parameters with 100% coverage, so the description does not need to add much. The phrase 'optional filters' adds no semantic detail beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('payment prescriptions'), making the operation unambiguous. It is naturally distinguished from the sibling tools payments_create_prescription, payments_update_prescription, and payments_delete_prescription, which represent different actions on the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly communicates when to use the tool: when you need to list payment prescriptions. However, it does not explicitly state when not to use it or how it compares to the create/update/delete siblings, leaving the agent to infer routing from the verb and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does convey that this is a read-only listing operation scoped to the current school year and that the pk parameter acts as an optional filter. However, it does not mention return format, pagination, ordering, or what happens if the class ID does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no unnecessary words. The primary purpose is stated first, and the optional filtering behavior is clearly and briefly mentioned second.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, one optional parameter, and no output schema, the description covers the essential operational details: what is listed, the time scope, and the optional filter. It is sufficient for an agent to select and invoke the tool correctly, though it could describe the response shape for greater completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents pk as an optional class ID with 100% coverage, so the baseline is 3. The description adds no new meaning beyond the schema: 'Optionally filter by class ID' simply restates the parameter's schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('classes'), and the scope ('for the current school year'). It also distinguishes this tool from the many attendance-related siblings by focusing specifically on classes, and mentions the optional class ID filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to use this tool versus alternatives, such as attendance_students, attendance_daily_schedule, or direct_attendance_lessons. It only states what the tool does; it does not say when not to use it or which sibling to choose instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal one non-obvious behavior: results incorporate current timetable changes rather than the static schedule, which is genuinely useful. It does not disclose what happens when no schedule exists for the date, whether the operation is reliably read-only, or any indication of the response shape — gaps that matter more because there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 19-word sentence that front-loads the verb and resource, then scope, then behavioral nuance. Every clause carries distinct information — person type, date granularity, and timetable-change awareness — with no filler or redundancy. This is a model of efficient description writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with full schema coverage and no nested objects, the description covers purpose, scoping, and the key timetable-changes behavior. The main gap is the absence of any statement about response shape or empty-result behavior, which is more salient given there is no output schema and no annotations; however, the resource name 'daily schedule' makes the return value reasonably self-evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented (pk = 'Person ID (staff or student)', date = 'Date in YYYY-MM-DD format'). The description essentially restates these concepts ('a person (staff or student)', 'a specific date') without adding formats, constraints, examples, or edge-case guidance. Per the rubric, baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('daily schedule'), and precise scope ('for a person (staff or student)', 'for a specific date'). The phrase 'reflecting current timetable changes' adds a distinguishing nuance that separates it from a static schedule tool. However, it never explicitly names or contrasts sibling tools like changed_timetable or attendance_bell_schedule, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario — you need one person's schedule for one date — and nothing more. It provides no explicit guidance on alternatives or exclusions; with overlapping siblings like changed_timetable, attendance_schedule_groups, and direct_attendance_student_overview nearby, the agent is left to infer when this tool is the right choice versus those. No when-not-to-use conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly signals a read-only listing operation and enumerates the data categories included, but it does not disclose default scope when no person_id is provided, whether students with no courses are included, or pagination behavior. There is no contradiction with any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundancy. Every phrase contributes meaning by naming the entities and data areas returned, making it compact and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with two optional parameters, no output schema, and no annotations, so the description carries moderate responsibility. It names the major return areas—courses, lessons, final evaluations, and attendance percentages—and the schema covers filter semantics. It does not specify row shape or default filtering behavior, but the description is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both person_id and evalterm_id are already documented. The description's 'students' and 'for an evaluation term' loosely map to the two parameters, but it adds no new parameter-level meaning beyond what the input schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and names the resource: students with their courses, lessons, final evaluations, and attendance percentages for an evaluation term. This composite scope is distinct from sibling tools like lessons_list or evaluations_list, though it does not explicitly name an alternative. The purpose is clear and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when a student-centric overview of courses, lessons, final evaluations, and attendance is needed for an evaluation term. However, it gives no explicit comparisons or exclusions relative to sibling tools such as attendance_students, lessons_list, or evaluations_list, so an agent must infer the exact selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. 'List all course types' implies a read-only list operation with no filtering, but it does not mention authentication needs, rate limits, pagination, or response format. The description adds little beyond what the tool name already suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the operation and resource, front-loading the core purpose. There is no filler, and every word contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool of minimal complexity, the description provides enough to invoke the tool correctly: it names the operation and the resource. The absence of output shape or sorting details is a minor gap for a simple list-all endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered with nothing to explain. The description appropriately focuses on the operation rather than parameter details, which would be redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('course types'), and the scope ('all'), which precisely defines the operation. This distinguishes it from sibling tools like lessons_rooms or lessons_work_types, which list different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as lessons_list or lessons_work_types. The description only states what the tool does, not when to select it or when not to use it, leaving the agent without selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'List' clearly signals a non-destructive read operation, which is the key behavioral trait here. However, it does not disclose output shape, ordering, pagination, or authorization requirements, though these are less critical for a zero-parameter list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately communicates the action and the object, which is ideal for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list tool, the description is nearly complete: it names the resource and the operation. The only mild gap is the absence of an output schema and no mention of what fields are returned for each bank account, but that is a minor omission given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so there are no parameter semantics the description needs to explain. With no parameters, the baseline is 4, and the description adds no unnecessary parameter-related clutter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a specific resource ('bank accounts configured in Edookit'), making the tool's purpose immediately clear. It does not explicitly differentiate from sibling payment tools like payments_categories or payments_types, so it misses the top level of sibling contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The resource phrase implies this tool is for retrieving bank accounts rather than other payment entities, but there is no explicit when-to-use or when-not-to-use guidance. No alternatives are named, so the agent must infer usage from the tool name and one-line description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral disclosure burden. It does add important context—output is pseudonymized/anonymous and covers the entire school history—but it leaves unclear how the optional 'date' parameter relates to the 'entire school history' claim and does not describe the response shape or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence leads with the verb and packs the two most decision-relevant facts—anonymization and full-history scope—up front. There is no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers the only parameter, so the description does not need much. Still, it leaves open what 'statistics' actually includes and how the reference date interacts with the 'entire school history' scope, which an agent may need to invoke or interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single optional 'date' parameter at 100% coverage, so the description is not required to repeat it. The description adds no extra meaning about how the date influences the statistics, which prevents a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'student statistics' and sharpens it with two qualifiers: 'pseudonymized (anonymous UUID)' and 'across entire school history.' These qualifiers also separate it from PII-based siblings like student_personal_data and per-student views like direct_attendance_student_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: call this when you need anonymized, school-wide student statistics rather than identifiable per-student records. However, the description names no alternatives and gives no explicit when-not-to-use conditions, so the agent must infer the boundary from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects; the verb 'Get' makes clear this is a read-only lookup. However, it does not describe not-found behavior, response shape, or any access requirements, so transparency is only minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler; every word carries meaning and the verb is front-loaded. It is a model of concise tool documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-nested-object read tool, the description covers the core operation and return cardinality. It still relies on sibling names for routing and provides no output or error details, but the task is simple enough that this is near-complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents pk as 'Passage ID' with 100% coverage. The description's 'by its ID' simply restates that semantic, adding no new format, constraints, or edge-case guidance; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Get'), a precise object ('single passage record'), and a lookup criterion ('by its ID'). The singular scope and ID-based lookup differentiate it from siblings like attendance_passages_by_date and attendance_insert_passage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving one specific passage when its ID is known, but it does not explicitly state when to use it instead of date-based or other passage tools. No alternatives or exclusions are named, leaving routing inference to sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It clearly indicates a read-only bulk retrieval operation and confirms the scope ('all... recorded on a given date'), but it does not disclose return format, pagination, ordering, or any limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the verb, target resource, and scope efficiently, earning its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, no-output-schema tool, the description is largely complete for selection and invocation. It identifies the resource and the date parameter sufficiently, though it does not describe what the returned passages look like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the only parameter, date, is already fully documented with format and meaning. The description adds no new semantic detail beyond referring to the date contextually, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('all RFID/physical access passages') and a precise scope ('recorded on a given date'). It clearly distinguishes itself from the sibling tools by date and by the passage-by-id tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever all passages for a date are needed. However, it does not explicitly state when not to use it or name alternatives like attendance_passage_by_id for individual passages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It makes clear this is a non-destructive listing operation and adds the behavioral detail that inactive staff are included. It does not mention permissions, pagination, or empty/invalid-ID behavior, but those are minor for such a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence conveys the verb, resource, scope, and optional filter with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter and no output schema, the description fully explains the operation and its main variant. It could add return-format details, but they are not essential for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is fully documented (100% coverage) and already describes pk as an optional staff ID. The description only echoes that optional filter behavior, adding no meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('List'), names the exact resource ('school staff'), and adds scope ('including inactive') and an optional filter by staff ID. This clearly distinguishes it from sibling tools such as attendance_students.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever a caller needs the full staff roster or a single staff member by ID. However, it does not explicitly name alternatives or state when not to use it, so the guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'No auth required,' which is a meaningful operational trait. It does not mention the return format or confirm the operation is a non-mutating GET, but 'Get' and 'version' make the read-only nature reasonably clear. This is minimally sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The resource and action appear first, followed by the only behavioral note (no auth). Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema version endpoint, the description captures the essential facts: what the tool returns (the service version) and the authentication requirement. It does not elaborate on response formatting or edge cases, but the low complexity makes that unnecessary. A slightly richer note on the return value would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description has no parameter semantics to add. The baseline for a parameterless tool is 4, and the description does not introduce any confusion about arguments because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Get') and a clearly identified resource ('Edookit Attendance (Docházka) service version'). This unambiguously distinguishes it from other attendance data tools and from version endpoints of other modules, so an agent knows exactly what operation is exposed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implicit from the name and description: call this tool to retrieve the Attendance service version. However, it gives no explicit guidance on when to choose this over alternatives, nor does it mention that no other version-check tool is needed for attendance. It is adequate but relies on the agent inferring the obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It does disclose the key filter ('only lessons that changed') and the legacy URL, but it does not mention output format, pagination, or explicitly confirm read-only behavior beyond the verb 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states the core purpose and the second adds the distinctive filter and legacy-URL caveat. Every sentence earns its place and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with three optional, schema-documented parameters, the description is largely sufficient: it states the scope, the filtering behavior, and a network detail. The lack of an output schema is mitigated by the resource name, though response format is not explicitly described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with clear descriptions for 'to', 'from', and 'teacherNameFormat'. The description adds no additional parameter-level context, so it provides no value beyond the schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Get'), names the exact resource ('substitution/changed timetable'), and adds a defining behavioral detail ('Returns only lessons that changed vs original schedule'). This clearly communicates what the tool does and distinguishes it from any general timetable or lesson-list tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: retrieving substitution/changed lessons for a date range. It does not explicitly name alternatives like lessons_list for the original schedule, but it gives clear enough context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'List' clearly indicates a read-only operation and 'available' adds scope, but the description does not mention pagination, ordering, permission requirements, or response format. This is adequate for a simple endpoint but not deeply informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. Every word contributes to explaining the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only listing tool, the description is largely complete: an agent knows what to call and why. The only notable gap is the absence of an output schema, so return fields are unspecified, but this is not critical for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema offers nothing to explain; the baseline for zero-parameter tools is 4. The description adds a contextual cue ('available in this Edookit instance') that clarifies the data scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('rooms'), with an explicit scope ('all ... in this Edookit instance'). This clearly distinguishes it from sibling tools dealing with lessons, attendance, payments, or other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicit: an agent can infer this is the tool for retrieving all rooms, especially since no sibling tool targets rooms. However, the description does not state when not to use it or compare it to any alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'List' clearly signals a read-only operation, which is the most important behavioral trait. However, it does not describe return format, ordering, pagination, or any access-related caveats, leaving room for ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundancy. Every word contributes to the meaning, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, list-only tool, the description is nearly complete: an agent knows the operation and target resource. The absence of an output schema means a bit more detail about the expected response could be helpful, but this is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is an empty object, so there is nothing for the description to explain beyond that. Since schema coverage is complete and no parameters exist, the lack of parameter-level detail is not a shortcoming.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List organizations in Edookit.' This clearly identifies the operation and the object being retrieved. Among the sibling tools, none cover 'organizations,' so the resource name distinguishes it without needing extra detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a list of organizations is needed, and it offers no misleading alternatives. However, it does not explicitly state when to prefer this over related payment tools or provide any exclusions. For a zero-parameter list tool, the implied usage is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It clearly implies a read-only list operation and adds the nontrivial constraint that filters are mandatory, but it does not mention authorization/privacy considerations for grade data, pagination, ordering, or the shape of returned records.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The action is front-loaded and the only non-obvious rule follows immediately, making the description easy to scan and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple filtered list operation, the description plus fully documented schema gives enough to invoke the tool correctly: what is listed, the mandatory filter condition, and the filter fields. It could be slightly richer by clarifying whether multiple filters combine with AND semantics and what the response records contain, but those gaps are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all five parameters, so the baseline is 3. The description adds a meaningful cross-parameter semantic: the tool is invalid without at least one of the three key filters, which is not apparent from the individually optional schema fields. This is genuinely useful beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List evaluations (grades)', which is a specific verb and resource, and the parenthetical immediately clarifies that evaluations mean grades. The name and description together make it distinct from all listed sibling tools, none of which target evaluations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a hard invocation precondition: at least one of student_id, course_id, or evalterm_id must be provided. This gives clear guidance on how to use the tool, even though it does not discuss when to prefer another tool because no sibling offers an overlapping evaluations endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses two useful behavioral details beyond the schema: the tool uses a legacy -login.edookit.net base URL and requires no authentication. The verb 'List' implies a non-mutating read operation. It could add return-format details, but these are not necessary for a simple public listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences contain exactly the required information: the action and the key operational context (legacy URL, no auth). No filler or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter list tool with no output schema and no annotations, the description covers purpose, auth requirements, and base URL. It does not describe the response format or date inclusivity, but these are minor given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies. The description's 'time range' phrase groups from/to semantically but does not add detail beyond what the schema already documents; the ical boolean is not mentioned in the description, but the schema covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('List public school events') and adds a clear temporal scope ('in a time range'). It unambiguously identifies what the tool does and is distinct from the attendance, lessons, payments, and direct_attendance siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use concrete: listing public school events within a time range. It also notes that no authentication is required, an important context for an agent deciding to call this tool. It does not name alternatives or exclusions, so it stops short of the explicit when-to-use guidance that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![edookit-mcp MCP server](https://glama.ai/mcp/servers/thewulf7/edookit-mcp/badges/card.svg)](https://glama.ai/mcp/servers/thewulf7/edookit-mcp)

Score Badge

Copy to your README.md:

[![edookit-mcp MCP server](https://glama.ai/mcp/servers/thewulf7/edookit-mcp/badges/score.svg)](https://glama.ai/mcp/servers/thewulf7/edookit-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/thewulf7/edookit-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server