Skolverket MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources like courses, subjects, programs, or adult education, with clear separation between search, get, and filter operations. However, some overlap exists, such as 'search_school_units' and 'search_school_units_by_name', which could cause confusion as both search for school units but with different filters. Descriptions help clarify, but the boundaries are not always perfectly distinct.
Naming Consistency5/5
Tool names follow a highly consistent snake_case pattern with a clear verb_noun structure throughout, such as 'get_course_details', 'search_adult_education', and 'filter_adult_education_by_distance'. All tools adhere to this convention, making them predictable and easy to understand, with no mixing of styles or chaotic naming.
Tool Count3/5
With 27 tools, the count is borderline high for a single server, as it covers multiple domains like adult education, curriculum, courses, subjects, programs, and school units. While comprehensive, it may feel heavy and could benefit from better scoping or modularization, but it's not extreme and remains manageable given the broad educational scope.
Completeness5/5
The tool set provides complete coverage for the educational domain, including search, get, and filter operations for all key resources like adult education, courses, subjects, programs, curriculums, and school units. It supports CRUD-like workflows (e.g., search then get details) and lifecycle aspects (e.g., version history), with no obvious gaps that would hinder agent functionality for educational planning and analysis.
Average 3.6/5 across 27 of 27 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on October 31, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns filtered education and provides an example parameter value, but doesn't describe pagination behavior (implied by page/size parameters), rate limits, authentication needs, error conditions, or what happens when no results are found. For a tool with 4 parameters and no annotation coverage, this is insufficient.
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 well-structured with clear sections (ANVÄNDNINGSFALL, RETURNERAR, EXEMPEL) and uses bullet points efficiently. It's appropriately sized for the tool's complexity. However, the first sentence could be more front-loaded with key information, and some sections could be more 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?
Given the tool has 4 parameters, no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain the searchTerm parameter's purpose, pagination behavior (page/size), return format details beyond 'Filtrerade utbildningar,' or how this tool differs from sibling search/filter tools. For a filtering tool with multiple parameters, this is inadequate.
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 0%, so the description must compensate. It only explains the 'distance' parameter ('true för endast distansutbildningar') and mentions 'distance=true' as an example. The other 3 parameters (searchTerm, page, size) are completely undocumented in both schema and description. The description adds minimal value beyond what's implied by parameter names.
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 tool filters education by distance (distance vs campus) with the phrase 'Filtrera utbildningar på distans eller campus.' This is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'filter_adult_education_by_pace' or 'search_adult_education,' which would be needed for a perfect score.
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 'ANVÄNDNINGSFALL' section provides three use cases that imply when to use this tool: finding distance-only education, filtering out distance options, and planning study alternatives based on location. However, it doesn't explicitly state when NOT to use it or mention alternative tools like 'search_adult_education' for broader searches, which would be needed for higher scores.
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 full burden. It states the tool returns a list of versions with dates, which is basic output information. However, it doesn't disclose important behavioral traits: whether this is a read-only operation (implied but not stated), potential rate limits, authentication requirements, error conditions, or pagination behavior for large result sets. The description adds minimal behavioral context beyond the basic return statement.
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 well-structured with clear sections (purpose, use cases, returns) and appropriately sized. Each sentence serves a purpose: stating the tool's function, providing context through use cases, and specifying the return format. However, the Swedish language might create minor accessibility issues for non-Swedish speaking agents, though the structure itself is efficient.
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?
Given no annotations, 0% schema description coverage, and no output schema, the description is incomplete. While it states the purpose and return format, it misses critical information: parameter documentation, behavioral constraints, error handling, and differentiation from similar version-tracking tools. For a tool with one required parameter and no structured documentation elsewhere, this leaves significant gaps for an agent trying to use it effectively.
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 0%, so the schema provides no parameter documentation. The description doesn't mention the 'code' parameter at all, leaving it completely undocumented. While the tool has only one parameter, the description fails to explain what 'code' represents, its format, or valid values, creating a significant gap in understanding how to invoke the tool correctly.
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 tool's purpose as 'Hämta versionshistorik för ett program' (Retrieve version history for a program), which is a specific verb+resource combination. It distinguishes from siblings like get_program_details (which likely shows current state) by focusing on historical versions. However, it doesn't explicitly contrast with get_course_versions or get_subject_versions, which handle similar version tracking for different 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?
The 'ANVÄNDNINGSFALL' (Use cases) section provides implied guidance on when to use this tool: for tracking program changes, comparing old/new program plans, and understanding vocational education development. This gives context but doesn't explicitly state when NOT to use it or mention alternatives like get_program_details for current information or search_programs for finding programs.
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 burden but only minimally addresses behavior. It mentions the tool returns a list with code, name, and status, but doesn't disclose important behavioral traits like whether this is a read-only operation, if there are rate limits, authentication requirements, pagination behavior, or what happens with no results.
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 has clear section headers (ANVÄNDNINGSFALL, RETURNERAR, EXEMPEL) which improves structure, but contains some redundancy. The example essentially repeats information already implied in the status parameter description. The front-loading is adequate but could be more efficient.
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 3 parameters, no annotations, and no output schema, the description provides basic context about what the tool does and returns, but leaves significant gaps. It doesn't fully compensate for the lack of structured metadata, particularly regarding behavioral characteristics and comprehensive parameter guidance.
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?
With 0% schema description coverage and 3 parameters, the description adds minimal value. It mentions filtering by status with example values, but doesn't explain the 'name' parameter's partial matching behavior or the 'limit' parameter's purpose. The schema itself provides parameter descriptions, but the tool description doesn't enhance understanding beyond what's in the structured schema.
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 tool searches for school units with filters, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'search_school_units_by_name' or 'get_school_units_by_status', which appear to offer similar functionality.
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 'ANVÄNDNINGSFALL' section provides implied usage contexts like finding schools in an area, filtering by status, building school registers, and planning/analysis. However, it doesn't explicitly state when to use this tool versus alternatives like 'search_school_units_by_name' or 'get_school_units_by_status' from the sibling list.
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 burden. It states the tool returns a list of curriculums with code, name, and validity period, which is helpful. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior, or error conditions. The description adds some value but leaves significant gaps.
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 well-structured with clear sections (description, use cases, returns, example). It's appropriately sized with no redundant information. Each sentence serves a purpose, though the Swedish language might add minor cognitive load for non-Swedish speakers.
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 3 parameters with 0% schema coverage and no output schema, the description provides basic purpose and return format but lacks parameter explanations. For a search tool with multiple optional parameters, this creates significant gaps. The description is minimally adequate but incomplete for effective tool selection and invocation.
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 0%, so the description must compensate. While it mentions searching for curriculums by school type and time period in the examples, it doesn't explain the three parameters (schooltype, timespan, typeOfSyllabus) or their relationships. The description adds minimal semantic context beyond what's implied by the tool name.
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 tool searches for curriculums (e.g., LGR11, GY11) with specific examples. It distinguishes from siblings like get_curriculum_details (which retrieves details) by focusing on search functionality. However, it doesn't explicitly differentiate from other search tools like search_courses or search_subjects beyond the curriculum focus.
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 'ANVÄNDNINGSFALL' section provides implied usage contexts: finding current curriculums, comparing between school types, and understanding structure. However, it lacks explicit guidance on when to use this tool versus alternatives like get_curriculum_details or get_curriculum_versions, and doesn't mention prerequisites or 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 provided, the description carries the full burden. It states what the tool returns ('RETURNERAR: Komplett programinformation' - Returns: Complete program information) and provides an example, but doesn't disclose behavioral traits like error handling, rate limits, authentication needs, or whether it's read-only. The description doesn't contradict annotations (none exist), but leaves significant behavioral aspects unspecified.
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 structured with clear sections (DESCRIPTION, ANVÄNDNINGSFALL, RETURNERAR, EXEMPEL), but contains some redundancy. The 'ANVÄNDNINGSFALL' section lists multiple use cases that essentially restate the purpose, and the 'RETURNERAR' section could be more concise. It's front-loaded with the core purpose, but could be more efficiently written.
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 2 parameters with 0% schema coverage, no annotations, and no output schema, the description provides basic purpose and return information but leaves significant gaps. It covers what the tool does and what it returns at a high level, but doesn't adequately document parameters, behavioral constraints, or how it differs from sibling tools. For a tool with this complexity level, it's minimally adequate but incomplete.
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 0%, so the description must compensate. While it mentions the 'code' parameter in the example ('code="NA" för Naturvetenskapsprogrammet'), it doesn't explain the 'version' parameter at all. The description adds minimal value beyond what's implied by the tool name, failing to adequately document the two parameters.
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 tool's purpose: 'Hämta detaljerad information om ett specifikt program' (Get detailed information about a specific program). It specifies the verb ('Hämta' - Get) and resource ('program'), but doesn't explicitly differentiate from sibling tools like 'get_program_versions' or 'search_programs' beyond the 'specifikt' (specific) qualifier.
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 'ANVÄNDNINGSFALL' (USE CASES) section provides implied guidance on when to use this tool (e.g., 'Djupdyka i programstruktur' - Deep dive into program structure, 'Planera studieväg' - Plan study path). However, it doesn't explicitly state when to use this versus alternatives like 'search_programs' or 'get_program_versions', nor does it provide exclusion 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 provided, so the description carries full burden. It states 'RETURNERAR: Lista över studievägar med koder' (returns: list of study paths with codes), which describes output format. However, it doesn't disclose critical behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, or pagination behavior. For a tool with no annotations, this leaves significant gaps.
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 well-structured with clear sections (description, use cases, returns). It's appropriately sized at 4 sentences/points. The information is front-loaded with the core purpose first. There's minimal waste, though the Swedish language might require translation for some agents.
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?
Given 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. While it states the purpose, use cases, and return format, it doesn't adequately cover parameter meanings, behavioral constraints, or detailed output structure. For a tool with this complexity and lack of structured documentation, more comprehensive description is needed.
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 0%, so the schema provides no parameter descriptions. The tool description mentions 'Filtrera efter typ' (filter by type) which loosely relates to the 'studyPathType' parameter, but doesn't explain any of the three parameters (schooltype, timespan, studyPathType) or their semantics. With 3 undocumented parameters, the description adds minimal value beyond what's in the bare schema.
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 tool's purpose: 'Hämta studievägskodar (programkoder)' translates to 'Get study path codes (program codes)'. It specifies the resource (study path codes/program codes) and the action (get/retrieve). However, it doesn't explicitly differentiate from sibling tools like 'get_program_details' or 'search_programs', which prevents a score of 5.
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 'ANVÄNDNINGSFALL' (use cases) section provides clear context: listing all high school programs, finding program codes, and filtering by type. This gives practical guidance on when to use the tool. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings, which would be needed for a score of 5.
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 mentions what the tool returns ('RETURNERAR: API-metadata och information'), but lacks details on permissions, rate limits, error handling, or other operational traits. For a tool with zero annotation coverage, this is a significant gap in transparency.
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 structured with sections for purpose, use cases, and return value, but it's somewhat verbose in Swedish and could be more streamlined. Sentences like 'Hämta information om Skolverkets Läroplan API' are clear, but the use case list is bulleted without additional explanation, making it efficient but not optimally concise.
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's simplicity (0 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers purpose and use cases but lacks behavioral details like response format or error conditions. For a basic info-fetching tool, it meets minimum viability but could be more comprehensive.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is acceptable here. Baseline is 4 for zero parameters, as it doesn't need to compensate for any schema gaps.
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 tool's purpose: 'Hämta information om Skolverkets Läroplan API' (Get information about the Swedish National Agency for Education's Curriculum API). It specifies the verb ('Hämta') and resource ('API'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_curriculum_details' or 'get_curriculum_versions', which might also involve API-related data, so it misses full sibling distinction.
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 includes an 'ANVÄNDNINGSFALL' (Use cases) section listing scenarios such as checking API version, contact information, and technical documentation, which implies when to use this tool. However, it doesn't provide explicit guidance on when not to use it or name alternatives among the many sibling tools, leaving usage context somewhat vague.
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 burden of behavioral disclosure. It states the tool returns a list of versions with dates, which is useful context. However, it doesn't cover other behavioral traits like whether it's read-only (implied by 'hämta' but not explicit), error conditions, rate limits, or authentication needs. The description adds some value but leaves gaps for a mutation-free tool.
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 well-structured with sections for purpose, usage cases, and return value, making it easy to scan. It's appropriately sized with no redundant sentences. However, the usage cases could be more integrated into the main description for better flow, slightly affecting structure.
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 1 parameter with low schema coverage and no output schema, the description provides basic purpose and return info but lacks details on parameter semantics and behavioral context. It's adequate for a simple read operation but incomplete for full agent understanding, especially without annotations to fill gaps.
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?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It mentions 'Läroplanskod' (curriculum code) indirectly in the purpose but doesn't explicitly describe the 'code' parameter's semantics, format, or constraints. This leaves the parameter meaning unclear beyond what's inferred, failing to fully address 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 clearly states the tool's purpose: 'Hämta versionshistorik för en läroplan' (Get version history for a curriculum). It specifies the verb 'hämta' (get) and resource 'versionshistorik' (version history), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_curriculum_details' or 'get_course_versions', which would require 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage cases ('Spåra revideringar', 'Jämföra olika versioner', 'Forskning om läroplansutveckling') that imply when to use this tool—for tracking revisions, comparing versions, or researching curriculum development. However, it lacks explicit guidance on when NOT to use it or alternatives (e.g., vs. 'get_curriculum_details' for current data), keeping it at an implied level.
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 the tool returns a list of directions, but does not describe behavioral traits such as whether it's a read-only operation, potential rate limits, authentication needs, or error handling. The description lacks critical behavioral context beyond the basic return statement.
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 structured with sections (description, use cases, returns), but includes some redundancy (e.g., 'ANVÄNDNINGSFALL' could be integrated more tightly). Sentences like 'Se specialiseringar' are brief, but the overall text could be more front-loaded and streamlined. It's adequately sized but not optimally concise.
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 0 parameters, no annotations, and no output schema, the description provides basic purpose, use cases, and return information. However, it lacks details on output format (e.g., structure of the list), error conditions, or integration with sibling tools. For a simple retrieval tool, it's minimally adequate but has clear gaps in completeness.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not mention parameters, which is appropriate. Baseline is 4 for zero parameters, as the description correctly focuses on other aspects without redundant information.
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 tool's purpose: 'Hämta alla inriktningar för utbildningar' (Get all directions for education). It specifies the verb ('Hämta' - Get) and resource ('inriktningar' - directions/orientations), but does not differentiate from sibling tools like 'get_education_areas' or 'get_study_path_codes', which might retrieve similar educational metadata. The purpose is clear but lacks sibling distinction.
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 includes an 'ANVÄNDNINGSFALL' (Use Cases) section listing scenarios like 'Se specialiseringar' (View specializations) and 'Filtrera utbildningar' (Filter education), which implies usage contexts. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'get_education_areas' or 'search' tools), nor does it provide exclusions or prerequisites. The guidance is implied but not comprehensive.
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 states the tool returns complete school unit info, which is helpful, but lacks details on behavioral traits like error handling, rate limits, authentication needs, or whether it's a read-only operation. The description doesn't contradict annotations (since none exist), but it's insufficient for a mutation-free tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, use cases, returns, and an example, making it easy to scan. It's appropriately sized with no redundant information. However, the use cases could be more concise, and the structure, while clear, isn't perfectly front-loaded as the key purpose is stated first but followed by less critical 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?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is moderately complete. It covers the purpose, parameter semantics, and return values adequately. However, it lacks behavioral context (e.g., read-only nature, error cases) and doesn't fully address usage guidelines relative to siblings, leaving gaps for an AI agent to infer 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 input schema has 1 parameter with 0% description coverage, so the description must compensate. It adds meaning by specifying that the 'code' parameter is an 8-digit school unit code in the example, which clarifies the format beyond the schema's generic string type. However, it doesn't detail validation rules or provide examples of valid/invalid codes.
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 tool's purpose: 'Hämta detaljer om en specifik skolenhet' (Get details about a specific school unit). It specifies the verb ('get details') and resource ('school unit'), making the purpose unambiguous. However, it doesn't explicitly differentiate from siblings like 'get_school_units_by_status' or 'search_school_units', which also retrieve school unit information but with different scopes or filters.
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 includes an 'ANVÄNDNINGSFALL' (use cases) section listing scenarios like checking school status or verifying school unit code, which implies when to use this tool. However, it lacks explicit guidance on when NOT to use it or alternatives (e.g., vs. 'search_school_units' for broader queries). The example mentions using an 8-digit code, providing some context but no clear 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 provided, the description carries the full burden of behavioral disclosure. It states the tool returns 'Komplett utbildningsinfo inkl. innehåll och krav' (Complete education info including content and requirements), which gives some behavioral context about the output. However, it doesn't mention whether this is a read-only operation, what permissions might be required, potential rate limits, error conditions, or other behavioral traits. The description adds value but doesn't fully compensate for the lack of annotations.
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 well-structured with clear sections (description, use cases, returns, example) and uses bullet points effectively. It's appropriately sized for the tool's complexity. However, the Swedish language might create minor accessibility issues for non-Swedish speaking agents, and some redundancy exists between 'detaljerad information' and 'Komplett utbildningsinfo'.
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 no annotations, no output schema, and minimal schema description coverage, the description provides reasonable context about what the tool does and when to use it. The use cases and return statement help, but significant gaps remain: no parameter documentation, no behavioral details beyond basic output description, and no differentiation from similar sibling tools. For a tool with this level of structured data deficiency, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage (only a basic 'ZodString' type). The description doesn't mention the 'id' parameter at all in the main text, though the example implies its use. This fails to compensate for the schema's lack of parameter documentation. The description should explain what the ID represents, where to obtain it, and any format requirements, but provides none of this semantic information.
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 tool's purpose: 'Hämta detaljerad information om ett utbildningstillfälle' (Get detailed information about an education instance). It specifies the verb ('hämta' - get/retrieve) and resource ('utbildningstillfälle' - education instance), making the purpose understandable. However, it doesn't explicitly differentiate from similar siblings like 'get_course_details' or 'get_program_details', which appear to serve related functions.
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 provides clear usage context through 'ANVÄNDNINGSFALL' (use cases) listing specific scenarios like viewing course information, reading course plans, checking admission requirements, and planning applications. It also includes an example mentioning 'Använd ID från search_adult_education' (Use ID from search_adult_education), which gives practical guidance. However, it doesn't explicitly state when NOT to use this tool or compare it to alternatives among the many 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 provided, the description carries the full burden. It states what the tool returns ('RETURNERAR: Skolenheter med angiven status') and lists the status values, which helps understand the tool's behavior. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, or pagination details (though 'limit' parameter hints at result limiting).
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 well-structured with clear sections (description, use cases, returns, status values). It's appropriately sized and front-loaded with the core purpose. Every sentence earns its place, though the Swedish language might require translation for some agents.
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's moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It covers the core purpose, use cases, and status values well, but lacks details about the 'limit' parameter, return format specifics, and behavioral constraints. For a filtering tool with no output schema, more information about what exactly gets returned would be helpful.
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?
The schema description coverage is 0%, so the description must compensate. While it lists the status values (AKTIV, UPPHORT, VILANDE) and mentions filtering by status, it doesn't explain the 'limit' parameter at all. The description adds some value for the 'status' parameter by providing the enum values, but completely ignores the 'limit' parameter, leaving half the parameters undocumented.
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 tool's purpose: 'Filtrera skolenheter efter status' (Filter school units by status). It specifies the verb (filter) and resource (school units), and the Swedish text is unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_school_units' or 'search_school_units_by_name', which likely offer broader search capabilities.
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 'ANVÄNDNINGSFALL' (USE CASES) section provides clear context for when to use this tool: finding active schools, listing closed schools, tracking dormant units, and statistics/analysis. This gives practical guidance, though it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools.
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 burden for behavioral disclosure. While it states the tool returns a list of education areas, it doesn't describe important behavioral aspects like whether this is a complete list or paginated, if there are rate limits, authentication requirements, or potential performance characteristics. The description provides basic return information but lacks operational context.
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 well-structured with clear sections (description, use cases, returns) and efficiently communicates essential information without unnecessary words. Each sentence serves a distinct purpose: stating the action, providing usage context, and specifying the return value.
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-only tool with no parameters and no output schema, the description provides adequate coverage of purpose and usage. However, without annotations and with no output schema, it should ideally describe the return format more specifically (e.g., structure of the education areas list, what fields are included) to be 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 tool has 0 parameters with 100% schema description coverage (empty schema). The description appropriately doesn't discuss parameters since none exist. It focuses instead on what the tool does and returns, which is correct for a parameterless tool.
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 tool's purpose with a specific verb ('Hämta' - Get) and resource ('alla utbildningsområden' - all education areas). It distinguishes itself from siblings by focusing on education areas rather than courses, programs, or other entities. However, it doesn't explicitly differentiate from similar tools like 'get_school_types' or 'get_study_path_codes' that might also return categorical data.
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 'ANVÄNDNINGSFALL' (Use cases) section provides clear context for when to use this tool: to see available areas, filter education searches, and explore education offerings. This gives practical guidance, though it doesn't explicitly state when NOT to use it or name specific alternative tools for different 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 provided, the description carries the full burden. It states what the tool returns ('RETURNERAR: Utbildningar med angiven studietakt') and lists valid values, which is helpful. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, if it has pagination behavior (implied by page/size parameters but not explained), rate limits, or authentication needs. The description adds some value but leaves gaps.
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 well-structured with clear sections (purpose, use cases, returns, values) and uses bullet points efficiently. Every sentence earns its place by adding value. It could be slightly more front-loaded by moving the return statement earlier, but overall it's appropriately sized and organized.
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 4 parameters with 0% schema coverage and no output schema, the description does a decent job explaining the core parameter (paceOfStudy) and return values. However, it doesn't cover the searchTerm, page, and size parameters at all, and with no annotations, it misses behavioral context like pagination mechanics or read/write nature. For a tool with this complexity, the description is incomplete but not entirely inadequate.
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 0%, so the description must compensate. It provides excellent semantic context for the 'paceOfStudy' parameter by listing valid values ('100', '50', '25', '50-100') with explanations. However, it doesn't address the other three parameters (searchTerm, page, size), which remain undocumented. The strong coverage of the primary parameter raises the score above baseline.
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 tool's purpose: 'Filtrera utbildningar efter studietakt' (Filter education by study pace). It specifies the verb (filter) and resource (education) with a clear criterion (study pace). However, it doesn't explicitly differentiate from sibling tools like 'search_adult_education' or 'filter_adult_education_by_distance', which would require 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'ANVÄNDNINGSFALL' (Use cases) section provides clear context for when to use this tool: finding full-time, part-time, or quarter-time education options, and adapting to work situations. This gives practical guidance. However, it doesn't explicitly state when NOT to use it or name alternatives among sibling tools, preventing a score of 5.
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. It states the tool returns version history with version numbers and dates, which is helpful behavioral information. However, it doesn't disclose important traits like whether this is a read-only operation, potential rate limits, authentication requirements, or error conditions. The description adds some value but leaves significant gaps in behavioral understanding.
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 well-structured with clear sections (main description, use cases, return information). Each sentence serves a purpose, and there's no wasted text. The information is front-loaded with the core purpose first. It could be slightly more concise by integrating the return information into the main description, but overall it's efficient.
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 no annotations, no output schema, and only 0% schema description coverage, the description does a reasonable job but has gaps. It explains the purpose, use cases, and return format, but doesn't cover error handling, authentication needs, rate limits, or detailed behavioral traits. For a tool with minimal structured data, it provides basic completeness but lacks depth for confident agent usage.
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 has 0% description coverage for its single parameter 'code', but the description compensates well by explaining in Swedish: 'Kurskod att hämta versioner för' (Course code to get versions for). This provides essential semantic meaning that the schema lacks. Since there's only one parameter and the description clarifies its purpose, this earns a strong score despite 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 clearly states the tool's purpose: 'Hämta alla versioner av en kurs' (Get all versions of a course). It specifies the verb ('Hämta' - Get) and resource ('versioner av en kurs' - versions of a course), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_course_details' or 'get_curriculum_versions', which could be related but serve different purposes.
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 'ANVÄNDNINGSFALL' (Use cases) section provides clear context for when to use this tool: tracking course changes over time, comparing old and new curricula, research/analysis, and understanding requirement/content evolution. This gives practical guidance, though it doesn't explicitly state when NOT to use it or mention alternatives among 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 provided, the description carries the full burden of behavioral disclosure. It states what the tool returns (a list of programs with specializations, profiles, and descriptions) and provides an example usage, which adds some context. However, it lacks details on error handling, pagination, rate limits, or authentication requirements, leaving gaps in behavioral understanding.
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 well-structured with sections for purpose, use cases, return values, and an example. It is front-loaded with the main purpose. Some sentences could be more concise (e.g., the use cases list is slightly verbose), but overall, it efficiently conveys key information without unnecessary fluff.
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 complexity (4 parameters, no output schema, no annotations), the description provides a good start with purpose, use cases, return format, and an example. However, it lacks details on parameter semantics for all parameters, error conditions, and behavioral traits like performance or limitations, making it incomplete for full contextual understanding.
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 0%, so the description must compensate for undocumented parameters. It only mentions 'schooltype' and 'timespan' in the example, providing some semantics (e.g., 'GY' for high school, 'LATEST' for timespan). However, it does not explain 'typeOfSyllabus' or 'studyPathType', leaving two parameters without any description, which is insufficient given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Sök efter gymnasieprogram och studievägar' (Search for high school programs and study paths). It specifies both the resource (programs/study paths) and the action (search), and distinguishes itself from siblings like 'get_program_details' (which retrieves details of a specific program) by focusing on search functionality.
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 provides clear usage contexts under 'ANVÄNDNINGSFALL' (use cases), such as study guidance, helping students choose programs, comparing study paths, and exploring specializations. It includes an example for high school programs. However, it does not explicitly state when not to use this tool or mention alternatives like 'search_adult_education' for non-high school programs.
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 states what the tool returns (list of subjects with code, name, description, version) and provides an example, but doesn't mention important behavioral aspects like pagination, rate limits, authentication requirements, or error conditions. The example helps but doesn't fully compensate for the lack of annotations.
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 well-structured with clear sections (description, usage cases, returns, example) and appropriately sized. Every sentence adds value, though the Swedish/English mix slightly affects readability. The front-loaded purpose statement is clear and followed by useful supporting 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?
Given 3 parameters with 0% schema coverage, no annotations, and no output schema, the description provides basic but incomplete coverage. It explains the purpose and return format adequately, but leaves significant gaps in parameter documentation and behavioral context. The example helps but doesn't fully address the complexity of a search tool with multiple optional parameters.
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?
With 0% schema description coverage and 3 parameters, the description fails to compensate adequately. While it mentions schooltype and timespan in the example, it doesn't explain typeOfSyllabus at all. The example provides some context for two parameters but leaves the third completely undocumented, and doesn't explain parameter relationships or constraints beyond what's minimally implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for subjects in the Swedish National Agency for Education's curriculum, specifying the resource (subjects) and context (curriculum). It distinguishes itself from sibling tools like get_subject_details or get_subject_versions by focusing on search functionality rather than retrieval of specific details or versions.
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 provides explicit usage cases (finding subjects by school type, comparing over time, exploring structure) which clearly indicate when to use this tool. However, it doesn't specify when NOT to use it or mention alternatives like search_courses or search_curriculums for different resource types.
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. It discloses that the tool returns a list ('RETURNERAR: Lista över läroplanstyper'), which is useful behavioral information. However, it doesn't mention other important traits like whether it's a read-only operation, potential rate limits, authentication needs, or error conditions. The description adds some value but leaves significant gaps.
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 well-structured and appropriately sized. It uses clear sections (purpose, use cases, returns) with bullet points for readability. Every sentence earns its place, and there's no redundant information. The Swedish language doesn't affect conciseness scoring.
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 that there's no output schema and no annotations, the description should do more to be complete. While it explains the purpose, use cases, and return type, it lacks details about the return format (structure of the list items), error handling, or any behavioral constraints. For a tool with zero parameters but potentially complex return data, this is adequate but has clear gaps.
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 with 100% schema description coverage (empty schema). The description doesn't need to explain any parameters, which is appropriate. It gets a baseline 4 since there are no parameters to document, and the description focuses correctly on the tool's purpose and output.
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 tool's purpose: 'Hämta alla typer av läroplaner' (Get all types of syllabi). It uses a specific verb ('Hämta' - Get) and resource ('typer av läroplaner' - types of syllabi). However, it doesn't explicitly differentiate from sibling tools like 'get_curriculum_details' or 'get_curriculum_versions', which might have overlapping domains.
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 includes an 'ANVÄNDNINGSFALL' (Use cases) section that provides clear context: 'Förstå olika läroplansk kategorier' (Understand different syllabus categories) and 'Filtrera sökningar' (Filter searches). This gives practical guidance on when to use the tool, though it doesn't explicitly state when NOT to use it or name specific alternatives among the 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. It discloses key behaviors: returns matching school units, supports partial name matching, and has a limit parameter. However, it lacks details on permissions, rate limits, error handling, or pagination, which are important for a search tool. This is adequate but has gaps.
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 well-structured with sections (description, use cases, returns, tips), uses bullet points efficiently, and every sentence adds value without repetition. It's appropriately sized and front-loaded with the core 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?
Given no annotations, 0% schema coverage, and no output schema, the description does a decent job covering purpose, usage, and key behaviors. However, it lacks details on output format (e.g., what fields are returned), error cases, or advanced usage, making it incomplete for full agent guidance. It's minimal but viable.
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 0%, so the description must compensate. It explains the 'name' parameter as supporting partial matching ('delmatchning', 'partiella namn'), which adds crucial meaning beyond the schema. The 'limit' parameter is mentioned in the schema but not in the description, leaving some gap. Since there are only 2 parameters and one is well-covered, a 4 is appropriate.
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 tool searches for school units by name with partial matching ('Sök skolenheter efter namn', 'delmatchning'). It distinguishes from siblings like 'search_school_units' (likely broader) and 'get_school_unit_details' (specific lookup), though not explicitly. However, it doesn't fully differentiate from all search siblings, keeping it at 4.
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 'ANVÄNDNINGSFALL' section provides clear context for when to use this tool: finding specific schools, filtering by name patterns, and identifying school groups. It implies usage but doesn't explicitly state when not to use it or name alternatives, so it's not a full 5.
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 full burden. It states what the tool returns ('Hela läroplanen med alla kapitel och avsnitt') and provides an example parameter value, but doesn't disclose important behavioral traits like error handling, rate limits, authentication requirements, or whether this is a read-only operation (though implied by 'Hämta').
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?
Well-structured with clear sections (description, use cases, returns, example). The Swedish text is efficient, though the example could be more integrated. Every sentence adds value, but the structure could be more front-loaded with the core 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 tool with 2 parameters, no annotations, no output schema, and 0% schema description coverage, the description provides good purpose and usage context but insufficient parameter documentation. It explains what the tool returns but not the format or structure of that return data.
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 0%, so the description must compensate. It only provides an example for the 'code' parameter ('code="LGR11" för grundskolans läroplan') but doesn't explain the 'version' parameter at all. With 2 parameters and no schema descriptions, this leaves significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Hämta komplett läroplan' - retrieve complete curriculum) and resource ('läroplan' - curriculum). It distinguishes from sibling tools like 'search_curriculums' by specifying it retrieves the complete curriculum with all sections rather than searching/filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines in the 'ANVÄNDNINGSFALL' section, listing four specific use cases (reading values/mission, reviewing goals, understanding frameworks, planning activities). It implicitly distinguishes from alternatives by specifying this retrieves complete curriculum details rather than searching or filtering.
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 states what the tool returns (list of school types with codes and names) and provides example values, which is helpful. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, if there are rate limits, authentication requirements, or how the data is sourced. The description adds some value but leaves significant gaps in behavioral understanding.
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 well-structured with clear sections (description, use cases, returns, values) and is appropriately sized. The Swedish language headings add some length but don't significantly impact conciseness. Every sentence serves a purpose, though the 'VÄRDEN' section could be more efficiently integrated.
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 this is a simple lookup tool with no output schema and minimal parameters, the description provides good contextual completeness. It explains what the tool does, when to use it, what it returns, and provides example values. The main gap is the lack of parameter documentation, but for a tool of this complexity, the description is reasonably 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 has 1 parameter with 0% description coverage. The tool description doesn't mention the 'includeExpired' parameter at all, so it adds no semantic information beyond what the schema provides. However, since this is a simple tool with only one optional parameter, the baseline score of 3 is appropriate - the schema must carry the full parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Hämta lista över alla skoltyper' (Get list of all school types). It specifies the verb ('get') and resource ('school types'), and distinguishes it from siblings like 'get_school_unit_details' or 'search_school_units' by focusing specifically on school type classification rather than school units 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an 'ANVÄNDNINGSFALL' (use cases) section that provides clear context for when to use this tool: to see available school forms, understand categorization, and filter data by school type. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, which prevents a perfect score.
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 clearly states what the tool returns ('RETURNERAR: Lista över alla versioner med versionsnummer och giltighetsdatum' - Returns: List of all versions with version numbers and validity dates), which is helpful. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, or error conditions. The description adds value but leaves significant gaps in behavioral understanding.
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 well-structured with clear sections (purpose, use cases, returns, tips), each containing precisely one sentence that earns its place. The Swedish text is direct and avoids redundancy. Despite having multiple sections, every element serves a distinct purpose without unnecessary elaboration.
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 moderate complexity (single parameter, list output), no annotations, and no output schema, the description does a good job covering essential aspects. It explains the purpose, provides rich usage scenarios, describes the return format, and offers follow-up guidance. The main gap is lack of behavioral details like safety profile or error handling, but for a read-oriented tool, this is reasonably 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 0% description coverage, so the description must compensate. It provides meaningful context about the 'code' parameter by explaining it represents 'Ämneskod att hämta versioner för' (Subject code to get versions for), which clarifies this is a subject identifier rather than a generic code. While it doesn't provide format examples or constraints, it adds essential semantic meaning beyond the bare schema.
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 tool's purpose: 'Hämta alla tillgängliga versioner av ett ämne' (Get all available versions of a subject). It specifies the verb ('hämta' - get) and resource ('versioner av ett ämne' - versions of a subject), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_subject_details' beyond mentioning it as a follow-up action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides excellent usage guidance with a dedicated 'ANVÄNDNINGSFALL' (USE CASES) section listing four specific scenarios: tracking changes over time, comparing current vs. previous curricula, researching curriculum changes, and understanding subject development progression. It also includes a 'TIPS' section that explicitly directs users to 'get_subject_details' for comparing specific versions, creating clear alternative usage pathways.
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 states what the tool returns (list of courses with specific fields) and provides an example, but doesn't mention pagination, rate limits, authentication requirements, or error conditions. The behavioral information is adequate but not comprehensive.
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 well-structured with clear sections (description, use cases, returns, example, tips) and each sentence adds value. It could be slightly more concise by combining some elements, but overall it's efficiently organized with no wasted text.
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 search tool with 4 parameters, 0% schema coverage, and no output schema, the description does an excellent job explaining purpose, parameters, and returns. It provides concrete examples and use cases. The main gap is lack of information about output format details beyond field names, but given the context, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides excellent parameter context. It explains what 'schooltype' and 'subjectCode' parameters do with concrete examples ('GY' for gymnasium, 'MATMAT01c' for Mathematics 1c), mentions filtering by school type and time period, and provides guidance on using subjectCode for filtering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for courses in Skolverket's curriculum with specific examples of use cases. It distinguishes from siblings like 'get_course_details' or 'search_subjects' by focusing on course search rather than retrieval of specific details or broader subject searches.
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 provides clear usage contexts through the 'ANVÄNDNINGSFALL' section with four specific use cases, and the 'TIPS' section offers guidance on parameter usage. However, it doesn't explicitly state when NOT to use this tool or mention specific alternatives among the many 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 provided, the description carries full burden. It discloses that the tool returns complete course information (including content, requirements, points, and objectives) and mentions it's the most used function for teachers. However, it doesn't address potential behavioral aspects like error handling, authentication requirements, rate limits, or whether it's a read-only operation (though 'get' implies read-only).
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 well-structured with clear sections (description, use cases, returns, example, important note). While slightly verbose, each section adds value: the use cases help understand when to use it, the returns section clarifies output, and the example provides concrete parameter guidance. No sentences feel wasted.
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 tool with 2 parameters, 0% schema description coverage, and no output schema, the description does a good job. It explains what the tool does, when to use it, what it returns, and provides a parameter example. The main gap is lack of explicit mention of the optional 'version' parameter, but overall it provides sufficient context for an agent to understand and use the tool effectively.
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 0%, so the description must compensate. It provides an example parameter value: 'code="MATMAT01c" för Matematik 1c' and explains that the tool retrieves details for a specific course. While it doesn't explicitly mention the optional 'version' parameter, the context of getting course details implies versioning might be relevant. The description adds meaningful context beyond the bare 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 clearly states the tool's purpose: 'Hämta detaljerad information om en specifik kurs' (Get detailed information about a specific course). It specifies the exact resource (course) and action (get details), and distinguishes itself from siblings like search_courses (which likely returns multiple results) and get_course_versions (which focuses on version history).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Detta är den mest använda funktionen för lärare!' (This is the most used function for teachers!) and lists specific use cases like course planning, analyzing grade requirements, understanding course objectives, and planning assessment. It clearly indicates this is the primary tool for detailed course information retrieval.
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 provided, the description carries the full burden. It discloses behavioral traits: it's a search/filtering tool (implied read-only), returns education instances with specific fields (title, location, pace, etc.), and includes pagination parameters (page, size with max 100). It doesn't mention rate limits, authentication needs, or error handling, but covers core behavior adequately for a search tool.
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 well-structured with sections (Use cases, Returns, Filter, Example), making it easy to scan. It's appropriately sized for a tool with 10 parameters, though some redundancy exists (e.g., 'Filtrera efter stad' in use cases and 'town' in filter). Every sentence adds value, but it could be slightly more streamlined.
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 complexity (10 parameters, no annotations, no output schema), the description is quite complete. It covers purpose, use cases, return values, parameters with semantics, and an example. However, it lacks details on output format structure, error cases, or pagination behavior beyond parameter names, leaving minor gaps for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It does so by listing all parameters in the 'FILTER' section with explanations and examples (e.g., 'searchTerm: Sökord', 'town: Stad', 'typeOfSchool: "yh", "sfi", "komvuxgycourses"', 'distance: "true"/"false"', 'paceOfStudy: "100" (heltid), "50" (halvtid)'), and includes additional parameters like 'page' and 'size' in the schema. This adds significant meaning beyond the bare 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 clearly states the tool's purpose: 'Sök vuxenutbildningar med omfattande filter' (Search adult education with comprehensive filters). It specifies the resource (adult education) and action (search with filters), and distinguishes from siblings like 'get_adult_education_details' (which retrieves details) or 'filter_adult_education_by_distance' (which is more specific).
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 'ANVÄNDNINGSFALL' (Use cases) section provides clear context for when to use this tool: finding YH, SFI, Komvux courses, filtering by location/distance/pace, and planning further education. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'search_courses' or 'search_programs' from the sibling list, though the focus on adult education implies some differentiation.
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 provided, the description carries full burden. It discloses key behavioral traits: it returns a complete list of all codes with type information, warns about large data volume and potential loading time ('Stor datamängd, kan ta tid att ladda'), and specifies the return format. However, it doesn't mention pagination, rate limits, or authentication requirements.
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 well-structured with clear sections (description, use cases, returns, notes), front-loaded with the core purpose, and every sentence earns its place. The Swedish text is efficient without unnecessary elaboration.
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 0 parameters, no annotations, and no output schema, the description provides good completeness: clear purpose, usage guidelines, return format, and performance warning. However, it could benefit from specifying exact return structure (e.g., array format) and any data freshness considerations.
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 with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's purpose and behavior, which adds value beyond the empty 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 clearly states the verb 'Hämta' (Get) and the resource 'alla tillgängliga ämnes- och kurskoder' (all available subject and course codes). It distinguishes from siblings by specifying it retrieves ALL codes without filtering, unlike search/filter tools in the sibling list that require parameters for specific queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'ANVÄNDNINGSFALL' (USE CASES) section explicitly lists three scenarios: exploring the entire course offering, finding correct codes for searching, and building overviews. This provides clear guidance on when to use this tool versus alternatives like search_courses or search_subjects that require specific parameters.
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 provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (retrieves detailed subject information), includes use cases that imply read-only behavior, and specifies the return format ('Komplett ämnesinformation med alla detaljer'). However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions, which would be helpful for a tool with no 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?
The description is well-structured and front-loaded with the core purpose, followed by organized sections for use cases, return values, and an example. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse for an AI agent.
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 complexity (a read operation with 2 parameters), no annotations, and no output schema, the description does a good job of being complete. It covers purpose, usage, parameters, and return values. However, it could improve by explicitly stating it's a read-only tool or mentioning any prerequisites, which would help compensate for the lack of structured data.
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 0%, so the description must compensate. It adds significant meaning beyond the schema: it explains that the 'code' parameter is for subject codes (e.g., 'GRGRMAT01' for mathematics) and provides an example, and it implies the 'version' parameter is optional by stating 'lämna tomt för senaste versionen' (leave empty for the latest version) in the schema. However, it doesn't fully detail all parameter behaviors or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Hämta detaljerad information') and resource ('ett specifikt ämne'), distinguishing it from siblings like get_subject_versions (which focuses on version history) or search_subjects (which searches rather than retrieves details). The Swedish text translates to 'Retrieve detailed information about a specific subject,' providing unambiguous intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an 'ANVÄNDNINGSFALL' (use cases) section that explicitly lists scenarios for using this tool: viewing central content, reviewing knowledge requirements, understanding subject structure and progression, and planning teaching. This provides clear guidance on when to use it versus alternatives like get_course_details or search_subjects, which serve different purposes.
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:

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

Score Badge

Copy to your README.md:

[![Skolverket-MCP MCP server](https://glama.ai/mcp/servers/isakskogstad/Skolverket-MCP/badges/score.svg)](https://glama.ai/mcp/servers/isakskogstad/Skolverket-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/isakskogstad/Skolverket-MCP'

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