noark5-tg-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools map cleanly to a distinct entity type or operation; the create_* family is split by Noark entity, and the search/filter tools are explicitly contrasted. Some overlap remains among the navigation/listing tools (noark5_list_children, noark5_entity_links, noark5_filter_entities, noark5_search_entities), so an agent needs to read descriptions carefully.
Naming Consistency4/5
All tools share the noark5_ prefix and snake_case, and the vast majority follow a clear verb_noun pattern (create_, get_, list_, delete_, update_, search_, filter_, upload_, download_). The main deviation is noark5_entity_links, which uses a noun phrase instead of a verb-first name.
Tool Count3/5
With 25 tools, the server sits at the upper edge of the borderline/heavy range. The Nooark domain is broad and the tools are individually meaningful, but many typed create operations plus multiple navigation/listing tools make the surface heavier than a typical lean MCP server.
Completeness4/5
The toolset covers the main hierarchy (arkiv, arkivdel, klasse, mappe, registrering, dokumentbeskrivelse), plus generic update/delete, search/filter, metadata lookup, and file upload/download. The main gap is that noark5_download_dokumentobjekt refrences a noark5_list_dokumentobjekter tool that is not actually exposed, although this can be worked around with list_children/entity_links.
Average 4.3/5 across 25 of 25 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It confirms a delete action and states that it returns confirmation or an error message, but it does not disclose irreversibility, permission requirements, cascading effects, or what happens if the entity has children or references. The term 'delete' is informative, but the description adds little beyond the name.
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 compact and front-loaded with the action. Every sentence serves a purpose: the action, the parameter meaning, and the return behavior. There is no filler or redundancy.
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 one-parameter delete operation, the description covers the essential invocation details: what to pass and what to expect in return. However, important safety context is missing, such as irreversibility, permissions, and relation constraints. The output schema exists but the description itself does not mention any behavioral caveats, so it is minimally adequate rather than 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?
Schema description coverage is 0%, so the description must define the parameter, and it does: 'entity_url: The self-href URL of the entity to delete.' This adds meaningful semantics beyond the schema's bare 'Entity Url' property, fully explaining what value to provide and why.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Delete an entity.' This distinguishes it from the many create/update/get/list siblings because delete is unique among them. It is slightly generic about what entity types are supported, but the action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus update_entity, get_entity, or other siblings. The description does not mention prerequisites, supported entity types, or exclusions. An agent must infer usage entirely from the tool name and one-line description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does state that a new entity is created and that the response includes the created arkviskaper's URL, which is useful. However, it does not mention credential requirements, potential duplicates, or other side effects beyond the obvious create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line purpose statement, an Args list, and a return statement. No filler or redundant content is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter creation tool, the description covers the parameters and the return behavior, and an output schema exists so detailed return values are not required here. It lacks usage context and any behavioral caveats, but the tool is simple enough that the description is mostly 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?
Schema description coverage is 0%, so the description must compensate. It explains arkviskaper_id as 'unique identifier,' navn as 'name,' and attributes as an optional JSON object with the optional field beskrivelse. This adds meaningful semantic value beyond the bare schema property 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 verb and resource: 'Create a new arkviskaper (archive creator).' It is distinguishable from sibling create-* tools by the explicit resource type, but it does not explicitly contrast itself with closely related alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over other create-* tools, nor any mention of prerequisites or context such as needing to create an archive creator before archival objects. The only usage signal is the implied 'create if that is what you want to do.'
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 supplied, the description carries the transparency burden. It discloses that the operation retrieves an entity and returns it 'formatted' with 'full details' and 'all fields and links,' which is useful. However, it does not state side effects, error behavior, authentication needs, or whether the entity URL must be previously obtained from a listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the main purpose, and organized into Args/Returns. Every sentence contributes useful information with no redundant filler.
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 single-parameter fetch tool, the description covers how to invoke it and what to expect in return. It could mention prerequisites such as credentials or relationship to sibling retrieval tools, but the presence of an output schema and the simplicity of the operation make this largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameter, and it does: it specifies that entity_url is the 'self-href URL' of the entity to fetch, adding meaningful semantic detail beyond the schema's bare string. This is enough for an agent to supply the correct value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get full details') on a specific resource ('entity') and clarifies that the entity is identified by URL. It is clear, though it does not contrast with sibling read tools such as noark5_get_root_links or noark5_entity_links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you already have an entity's self-href URL, but it gives no explicit guidance on when to choose this over siblings, no conditions, and no mention of prerequisite steps like setting credentials. It provides no exclusions or alternatives.
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 behavioral disclosure burden. It states the create side effect and that the response includes details and the URL of the created mappe, which is helpful. However, it does not mention error behavior, required credentials, or what happens on invalid parent_url; this is a moderate gap for a mutation tool with zero 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 front-loaded with the core action and then gives a compact parameter list. It is mostly efficient, though there is some redundancy in calling attributes 'Optional' and then saying 'All optional' again in the same bullet.
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 create operation with no annotations and a low-detail schema, the description covers the main requirements: what it creates, under which parents, all parameter meanings, and the shape of the return value. It could be more complete with an example JSON attributes string and error semantics, but it is adequate for correct invocation in most cases.
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 for the schema's silence. It does so by explaining all four parameters: parent_url, tittel, beskrivelse, and attributes, and it enumerates the accepted optional attribute keys. This adds significant meaning beyond the bare input 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 'Create a new mappe (file) under a parent entity', naming the specific verb, resource, and the allowed parent types (arkivdel, klasse, or mappe). It does not explicitly contrast it with siblings like noark5_create_saksmappe or noark5_create_klasse, so it earns a 4 rather than 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 description provides clear context by specifying where a mappe can be created: under an arkivdel, klasse, or mappe. It does not enumerate exclusions or explicitly route away from sibling create tools, but the parent-type constraint gives the agent enough context to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It clearly indicates a create operation, documents accepted optional fields, and states that the created registrering's details and URL are returned. It does not disclose authentication needs, idempotency, or error behavior, but the essential side effect is clear.
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: a clear one-sentence purpose, a compact Args section, and a short return note. The optional attribute list is somewhat long but earns its place because the schema provides no such detail; there is no filler or tautology.
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?
It is callable: all required inputs are explained, optional fields are listed, and the return is described. However, for a write tool with no annotations, it lacks explicit alternative routing (generic registrering vs journalpost/arkivnotat) and prerequisite hints such as credentials or how to obtain mappe_url. The presence of an output schema partially compensates for return-value detail.
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 provides only names and types with zero descriptions, so the description adds substantial meaning: mappe_url is identified as the parent's self-href, and attributes is expanded with a full list of accepted optional keys. The only weakness is calling attributes a JSON object while the schema types it as a string, which leaves some passing-format ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the exact operation (create) and resource (Noark5 registrering) plus the required parent container (mappe). The entity name and parent context distinguish it from sibling tools such as create_mappe and create_journalpost at the resource level.
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 mappe_url parameter and 'under a mappe' phrase imply this is for adding a registration to an existing mappe. However, there is no explicit guidance on when to use this over create_journalpost, create_arkivnotat, or other create-* siblings, so the selection criteria are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the return behavior ('Returns details of the created arkivdel including its URL') and clarifies that the attributes object is entirely optional, which is useful. It does not address authentication requirements, failure modes, idempotency, or side effects of duplicate creations, leaving the error/safety profile undisclosed but acceptable for a straightforward create operation.
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 one-line summary is front-loaded, followed by a compact Args section and a return-value note. The optional-field enumeration is long but earns its place given the bare schema titles. The structure is scannable, though slightly dense in the attributes line.
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 create operation that has an output schema, the description covers the creation target, parent relationship, required and optional inputs, and the return value. It omits error/edge-case behavior and authentication context, but the sibling set_credentials tool signals where auth is handled, and these gaps are minor for a straightforward creation 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 fully compensates: arkiv_url is explained as the parent fonds self-href, tittel as the new arkivdel's title, and attributes is not only marked optional but enriched with a complete enumeration of 13 accepted fields (beskrivelse, arkivdelstatus, dokumentmedium, etc.). An agent can construct a fully correct call from the description alone.
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 opening line states a specific action, 'Create a new arkivdel (series/partition) under a fonds,' naming a concrete resource type and its parent container. Within a large family of create_* siblings (create_mappe, create_arkiv, create_klasse), naming the exact Noark5 entity and its placement distinguishes this tool without needing to inspect the schema. The parenthetical English gloss '(series/partition)' further clarifies the domain term.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'under a fonds' and the required arkiv_url argument imply the prerequisite of an existing parent fonds and establish the creation context. However, the description never explicitly names alternatives, exclusions, or 'when not to use' conditions, such as which sibling handles top-level arkiv creation. Guidance remains inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
As no annotations are provided, the description carries the burden of disclosing behavior. It clearly states it creates a resource and returns details including its URL. However, it does not disclose required permissions, potential side effects, error behavior, or what happens if the parent saksmappe does not exist. This is a moderate gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear one-line purpose, then an Arguments section, then a return statement. It is longer than necessary because of the detailed attribute list, but that detail is valuable given the schema's lack of descriptions. No fluff.
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 input schema and the presence of an output schema, the description covers all parameters and the return value with sufficient detail. It does not mention authentication setup or failure scenarios, but for a create call within an established Noark5 context this is acceptable. Minor gap: no guidance on whether attributes must be JSON-escaped or how the JSON string is parsed.
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 zero schema description coverage, the description fully compensates by explaining every parameter in the Args section. It specifies that saksmappe_url is the self-href URL of the parent, tittel is the title, and attributes is an optional JSON object enumerating the allowed fields. This goes well 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 specific operation: 'Create a new arkivnotat (record note) under a saksmappe.' This gives a verb, a resource type, and the parent context. It is easily distinguished from sibling create tools, which target different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the parent resource type 'saksmappe' and the record-note nature. However, it does not explicitly say when to choose this over alternatives like noark5_create_registrering or noark5_create_journalpost, nor does it mention prerequisites such as setting credentials first.
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 clearly discloses that this creates a new journalpost and mentions the return value, which covers the basic mutation behavior. It does not address prerequisites, authentication, or consequences for the parent saksmappe, but the core side effect is stated.
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: a one-sentence purpose, a clear Args section, and a return note. The long attribute list is justified because the schema provides no property details, though it makes the description lengthy.
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 three-parameter creation tool with an output schema, the description gives all necessary parameter semantics and states the return includes the created entity URL. It could add guidance about required credentials or confirming the parent saksmappe exists, but it is otherwise complete enough for correct invocation.
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%, but the description fully documents each parameter: saksmappe_url is the self-href URL of the parent, tittel is the title, and attributes is an optional JSON object with the complete list of accepted fields. This adds substantial 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 opens with a clear verb and resource: 'Create a new journalpost (registry entry) under a saksmappe.' It specifies the parent context and distinguishes journalpost creation from generic registrering or mappe creation among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended parent context clear ('under a saksmappe') and documents the required saksmappe_url, so an agent can infer when this tool applies. However, it does not explicitly contrast it with alternatives such as noark5_create_registrering or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the operation creates a new entity and that the response includes details and a URL, but it does not mention side effects, permissions, validation, or failure behavior beyond that.
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 front-loaded with the core purpose, then organized into concise Args and Returns sections. The optional field list is informative and does not add fluff.
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 straightforward creation tool, the description covers all parameters and return expectations. It could be more complete with usage guidance and behavioral caveats, but an agent has enough to correctly invoke this tool given a parent arkivdel URL.
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 itself has zero descriptions, so the description must compensate. It explaines arkivdel_url, tittel, and attributes, and lists all optional attribute fields. The only weakness is calling attributes a 'JSON object' while the schema types it as a string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new klassifikasjonssystem') and the placement ('under an arkivdel'), with a parenthetical translation. This distinguishes it from related sibling create tools by naming a distinct resource and its hierarchical parent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by requiring the parent arkivdel URL and stating the object is created under an arkivdel. However, it does not explicitly say when to choose this tool over alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals the four link categories, notes that entities can have multiple parents, and explains query-template URLs. This makes the read-only discovery purpose clear.
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 a clear opening, bullet-like category details, and usage pointers. The final sentence 'Returns categorized list of links with URLs and descriptions' is somewhat redundant with the opening, but it does not bloat the description much.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers categories, usage guidance, parameter semantics, and an output schema exists. However, the reference to the nonexistent 'noark5_navigate_up' tool and the lack of explicit relationship to the similar sibling tools noark5_list_children and noark5_list_parents leave a meaningful completeness gap.
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 defines entity_url as 'the self-href URL of the entity to inspect,' which adds meaningful context beyond the bare schema type. It stops short of an example or how to obtain the self-href, but is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource—'List all navigation links on an entity, categorized by type'—which clearly distinguishes it from siblings like noark5_list_children and noark5_list_parents. The category breakdown further clarifies its scope.
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 gives explicit pointers: use noark5_filter_entities for filtered listing and 'noark5_navigate_up' for parent details. However, 'noark5_navigate_up' does not appear among the sibling tools, and the actual sibling noark5_list_parents is not referenced, making the guidance partially misleading. It also does not contrast against noark5_list_children or noark5_list_parents.
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 transparency burden. It does disclose that this is a creation operation and that the response contains created-class details including its URL. However, it does not mention side effects beyond creation, authorization requirements, behavior on invalid parent URLs, or how optional attributes affect the created entity.
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 content is compact and functional: one purpose sentence, a clear parameter list, and a return-value statement. It avoids filler while covering all parameters and the response, and the primary purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity creation tool with three parameters and an output schema signal, the description supplies enough to call it: parent context, title, optional fields, and return information. It could be more complete by covering failure modes or hierarchical restrictions, but it does not leave fundamental invocation questions unanswered.
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 fully compensate. It explains parent_url as a self-href URL and clarifies which parent types are valid, defines tittel, and enumerates the optional attribute fields. The main gap is that the schema types attributes as a string while the description says 'JSON object', which is slightly ambiguous about whether a JSON-encoded string is expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and resource ('a new klasse'), and pins down where the object belongs ('under a klassifikasjonssystem or another klasse'). This clearly distinguishes it from sibling creation tools such as noark5_create_klassifikasjonssystem, noark5_create_mappe, and noark5_create_arkivdel.
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 gives clear usage context by specifying the valid parent types (klassifikasjonssystem or klasse), so an agent can infer when this tool applies. It does not explicitly name alternatives or exclusion cases, but the parent-type condition provides practical routing guidance among the many create_* 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 behavioral burden. It discloses server auto-assignment behavior for saksaar, the optional nature of attributes, and that the response includes the created object's URL. It does not cover authorization, idempotency, or failure behavior, but the core mutating behavior is clear.
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 purpose is front-loaded in a single sentence, followed by a structured Args/Returns layout. The field list is long but necessary because the schema provides no descriptions, so the density is justified.
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 4-parameter create tool with no annotations, the description covers all parameters, the required parent type, optional field semantics, and the response. It could additionally address error scenarios or explicitly route to sibling create tools, but it is sufficient for correct invocation.
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%, and the description fully compensates: it explains parent_url, tittel, saksaar, and attributes, including the full list of optional fields and inherited Mappe fields. It also clarifies that saksaar=0/omitted triggers server auto-assignment and that attributes is a JSON object despite being typed as a string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Create a new saksmappe (case file) under an arkivdel.' It identifies the entity type and the required parent, which separates it from sibling create_* tools even without naming them.
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?
Provides clear context: this tool is for creating a saksmappe and requires a parent arkivdel, with parent_url explicitly described. It does not mention exclusions or alternatives like noark5_create_mappe, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It clearly states the side effect (creating a fonds) and mentions that details and URL are returned, but it does not disclose required credentials, failure behavior, or duplicate-handling behavior. This is adequate but not rich.
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 core purpose is stated in the first sentence, followed by a compact parameter list and a short return note. Every sentence adds value, and there is no redundant filler.
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 two-parameter create tool with an output schema, the description is largely complete: it defines all parameters, the optional attribute fields, and the return behavior. It only omits an explicit prerequisite note about calling noark5_set_credentials first, which is a minor gap given the sibling tools.
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%, and the description fully compensates. It explains that 'tittel' is the title of the fonds and defines 'attributes' as an optional JSON object while enumerating every supported optional field. An agent can construct a correct call without needing additional documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a new top-level archive (fonds).' The phrase 'top-level' clearly distinguishes this from related sibling tools like noark5_create_arkivdel, making the tool's purpose unambiguous.
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 context: use this tool when creating a new top-level fonds. It implicitly rules out sub-archive creation, but it does not explicitly name alternatives or state a when-not condition, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It states that a new dokumentbeskrivelse will be created and that details, including the URL, will be returned. It does not cover error cases or idempotency, but for a straightforward create operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is stated in the first sentence, followed by a compact and organized Args section. Every line adds useful information about the parameters or return value, with no filler.
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?
An output schema exists, so exhaustive return-value documentation is not required. The description covers the parent-child relationship, required arguments, optional fields, and return URL. It could be improved by giving an example of the attributes JSON or noting the string serialization, but it is complete enough for invocation.
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 registrering_url, tittel, and attributes, and lists all optional attribute fields. The only notable gap is that attributes is schema-typed as string but described as a 'JSON object' without clarifying it should be passed as a JSON string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Create', and names the exact resource, 'dokumentbeskrivelse (document description)', plus its parent context, 'under a registrering'. This clearly distinguishes the tool from the many other create_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when this tool is used: creating a document description under a specific registrering, and it identifies the required parent URL. It does not explicitly mention alternatives or exclusions, so it falls just short of a perfect score.
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 explains that discovery is HATEOAS-based, follows N5TG-compliant link detection, handles over{xx} recursive relations, and returns all current parents with details. It does not explicitly state that the operation is read-only or describe failure modes, but the 'list' intent and traversal details are conveyed clearly.
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 moderately detailed but every paragraph earns its place: core purpose, standards-based discovery, multi-parent caveats, then argument definition. The N5TG chapter references are slightly verbose, but they add grounding for the traversal behavior rather than being filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read operation with an output schema present, the description covers the important edge cases: multiple parents, different parent types, recursive hierarchies, and returned fields (titles, types, URLs). It could additionally note authentication prerequisites or empty-result behavior, but nothing critical is missing.
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%, yet only one parameter exists and the description fully compensates: it defines entity_url as 'the self-href URL of the entity to list parents for.' This adds material meaning beyond the bare string type in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'List all parent entities of an entity using HATEOAS discovery.' This clearly distinguishes it from the sibling noark5_list_children, which handles the opposite direction, and from noark5_entity_links, which likely exposes raw link structures.
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 context for when it applies: when you need all current parents, including recursive hierarchies and entities that can have multiple simultaneous parents. However, it does not explicitly name alternative tools or state when not to use it, so it lacks the explicit exclusion/alternative routing that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavior. It explains that the tool resolves the href from _links, POSTs raw binary content, and returns JSON of created/updated instances with typical metadata fields. This is substantive and transparent about mechanism and side effects, though it does not mention authentication requirements or potential errors.
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 and front-loaded: core statement, prerequisite condition, discovery hint, mechanism, args, and return summary. It is slightly redundant—the return behavior is stated twice—but every section earns its place and the formatting aids parsing.
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 complexity, the description covers the necessary prerequisites, how to determine if an entity supports upload, the HTTP mechanism, and the expected response. An output schema exists, so return values are already structured. A small gap is lack of mention of authentication or failure cases, but the description is otherwise sufficient.
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, and it does. The Args section adds meaning to all three parameters: entity_url is a self-href URL with a fil relation, file_path is a local file path, and mime_type has a stated default. This goes well beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Upload a file to an entity that has a fil relation key.' It clearly differentiates this from sibling tools like create_dokumentbeskrivelse or download_dokumentobjekt by tying upload capability to the presence of a specific relation key in _links.
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 gives concrete guidance on when this tool applies: any entity whose _links contains the specified fil relation key supports upload, and it names discovery tools (noark5_entity_links or noark5_list_children) to verify eligibility. It does not explicitly state when not to use it or compare against alternatives like create_dokumentbeskrivelse, so it misses the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that discovery is HATEOAS-based, that available child collections are auto-discovered and each type is fetched, and that the result is a grouped list or an error message. It does not mention pagination or the number of requests caused by fetching each type, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: summary, usage modes, Args, and Returns. Every sentence adds value, and the most important behavioral distinction is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-optional-parameter tool with an output schema and no annotations, this description is nearly complete: it explains the discovery mechanism, parameter semantics, and return shape. The main gap is the slightly misplaced upward-traversal reference and lack of pagination detail, but an agent can invoke it correctly.
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 property descriptions are 0% covered, but the Args section fully compensates: parent_url is explained as the self-href URL and omit for top-level, and filter_str is explained as an optional OData $filter applied to each collection. Both parameters receive meaningful, actionable semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List all children of an entity using HATEOAS discovery,' which is a specific verb and resource. It then clarifies the two modes (top-level listing without parent_url, child collections with parent_url), so the agent can distinguish this from upward-traversal and search tools.
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?
It explicitly states when to omit parent_url (top-level entities) and when to supply it (children of a specific entity). It also references upward traversal via noark5_navigate_up, giving an alternative cue, though that tool name does not appear in the sibling list and noark5_list_parents would be the clearer pointer.
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 explains the two operational modes, the effect of empty arguments, OData filtering syntax with examples, and the return format (formatted list of kode/kodenavn). It does not mention pagination or limits, but the behavior described is sufficient for a simple read-only listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loaded with the core purpose, and uses concise sections for usage, examples, and arguments. The OData examples are practical and earn their place, and there is no redundant filler.
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?
The tool is fairly simple with two optional parameters, and the description covers purpose, argument behavior, filtering syntax, and return shape. Minor gaps include not explicitly addressing pagination or whether filters are mandatory for large catalogs, but the description is otherwise complete and actionable.
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?
The input schema provides no parameter descriptions (0% coverage), so the description fully compensates by explaining each parameter in detail, including example values, the meaning of an empty catalog_name, and the syntax of filter_str with concrete OData examples. This adds substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List or search metadata posts (katalogpost) within a specific catalog,' using a specific verb and resource. It further distinguishes itself from general entity search siblings by focusing on katalog metadata and naming concrete catalog examples.
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 practical guidance on when to omit filter_str versus when to provide an OData filter, and explains that an empty catalog_name lists all available catalogs. It does not explicitly name alternative sibling tools or state when not to use them, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that authentication is required, that some returned relations require authentication, and that the output includes top-level navigation endpoints. It does not discuss failure modes or explicitly confirm read-only behavior, but for a simple root-links GET this is adequate and useful.
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 front-loaded with the core purpose and keeps every sentence purposeful. The additional guidance about noark5_entity_links and noark5_filter_entities is relevant and non-redundant, making the length justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and the operation is a simple read of root links, the description covers prerequisites (authentication), what is returned, and how to continue the workflow. Nothing essential is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to document. Baseline for zero-parameter tools is 4, and the description appropriately focuses on behavior and follow-up steps rather than inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a specific resource ('root API links'), and clarifies that it returns all available relations from the API root, including authenticated ones. It is clearly distinct from sibling tools like noark5_entity_links, which operates on a specific URL rather than the root.
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 gives explicit workflow guidance: use this tool after login to reveal top-level navigation endpoints, then follow a link and use noark5_entity_links for entity-specific discovery, and pass cleaned base URLs to noark5_filter_entities. This effectively tells an agent when and how to use it relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavior disclosure. It clearly reveals this is a mutating operation ('Create'), explains the underlying modelling, and states that details of the created entity are returned. It could additionally cover prerequisites or failure behavior, but the core behavioral outcome is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then gives a compact rule for using it, a useful mapping of common types, and a clean Args list. Every sentence contributes; the examples replace what would otherwise be vague parameter explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter creation tool with an output schema, the description covers all required inputs, gives example values, explains the parent relationship, and notes the return value. An agent has enough context to invoke it correctly without needing additional documentation.
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 coverage is 0%, so the description must compensate, and it does: it defines parent_url as 'the self-href URL', lists common entity types with their field names, and maps each argument to a meaningful role. This goes well beyond the bare schema titles and gives the agent enough to construct valid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Create a secondary ... entity under a parent') and gives concrete examples ('forfatter, noekkelord'). It also explicitly distinguishes this tool from noark5_update_entity, so an agent can tell them apart without inspecting schemas.
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?
It explicitly says 'Use this instead of noark5_update_entity to add them,' providing direct guidance on when this tool is the right choice. The cardinality explanation ([0..*]/[1..*]) also gives a clear condition for when secondary entities are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 explains that the tool resolves a HATEOAS link, downloads binary content to disk, creates a temporary file in /tmp when no path is given, and explicitly warns that temporary files are not automatically removed. This is strong, non-obvious behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: a one-line summary, a mechanism note, a prerequisite pointer, and structured Args. Every sentence provides actionable information; the temporary-file cleanup warning earns its place because it prevents an unanticipated side effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter download tool with no annotations, the definition covers the target resource, how the URL is discovered, the download behavior, the output location rule, cleanup responsibility, and return value. Nothing critical is missing for an agent to invoke it correctly.
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 fully compensate. It does: dokobj_url is explained as the self-href URL of the dokumentobjekt, and output_path is explained with its optionality and default temp-file behavior. Both parameters receive meaning beyond their raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Download file content from a dokumentobjekt.' It then explains the mechanism (resolving the referanseFil HATEOAS link) and the disk-write behavior, which clearly distinguishes it from generic get/entity tools and from the sibling noark5_upload_file.
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 gives clear usage context by instructing the agent to run noark5_list_dokumentobjekter first to obtain the target URL. It does not explicitly state when not to use this tool or name alternatives, so it stops short of a 5, but the prerequisite workflow is clear enough for an agent to select it correctly.
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 explains that the tool operates on one collection at a time, supports full OData expressions, lists all entities when filter is empty, and returns formatted results with systemID, title, and URL. This is strong behavioral context, though it does not discuss edge cases such as invalid filters or empty collections.
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: purpose, usage guidance, contrast with sibling, examples, then parameter details. Every section earns its place, and the examples are useful rather than redundant. It is detailed but not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter filtering tool with no annotations, this description is complete. It covers what the tool does, when to use it versus alternatives, parameter semantics, concrete filter syntax, and the return shape. The presence of an output schema lowers the need to explain return values further, though it does anyway.
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: collection_url is explained as the base URL without the {?$filter} suffix, filter_str is described as an optional OData expression, and concrete examples show acceptable syntax. This goes well 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 opens with a precise verb-resource pairing: 'List or filter entities from a specific collection URL using OData $filter.' It clearly distinguishes itself from noark5_search_entities, which searches globally, so an agent can tell the tools apart without inspecting sibling schemas.
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?
It explicitly states when to use the tool: when you have a known collection URL from noark5_entity_links or noark5_list_children and need field-level filtering. It also contrasts with noark5_search_entities, giving a clear alternative and the condition that selects it. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that search is full-text and case-insensitive, limited to title matching, that $filter is ANDed with the search term, and that results include URLs, titles, and types. It could add more about pagination or error behavior, but the core behavioral traits are clearly explained.
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, starting with a one-sentence summary, then usage guidance, parameter explanations, and return format. Every sentence carries meaningful information and none repeats schema fields unnecessarily.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero annotations and zero schema descriptions, the description covers purpose, when to use it, parameter semantics, and return format. It also names the relevant sibling tool for the alternative use case, making it sufficiently complete for an agent to select and invoke correctly.
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 fully compensates. It explains query as a title-matching full-text, case-insensitive term, and filter_str as an optional OData $filter expression with a concrete example. This gives the agent everything needed to construct both arguments correctly.
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 a specific verb and resource: global search across all entity types using a title-matching $search term with optional $filter. It explicitly distinguishes itself from noark5_filter_entities, making its scope easy to understand.
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?
It provides explicit usage guidance: use this tool for global keyword search optionally constrained by a condition, and use noark5_filter_entities instead when filtering a known collection URL from entity links or children. This gives an agent clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It details both supported auth flows, token renewal via refresh_token, auto-detection of OIDC vs Basic, default base_url behavior, and the success return content.
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 structured with clear bullets and an Args section. It is moderately long but every sentence adds useful information, with the core purpose stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of annotations, the description covers the essential setup logic, authentication methods, defaults, and return value. An agent has enough context to call this tool correctly without further clarification.
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%, but the description compensates fully by documenting every parameter: username, password, base_url, auth_method, and client_id, including defaults, allowed values, and behavioral implications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action, 'Set authentication credentials for the Noark 5 API', and clearly distinguishes it from the entity-focused sibling tools. The resource and purpose are immediately evident.
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 context for when this tool is used: setting up authentication before working with the API. It explains the auth_method options and auto-detection behavior, though it does not explicitly state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses merge PATCH semantics (RFC 7396), that unchanged fields are preserved server-side, that sub-resources are not updatable this way, and that _links can reparent an entity. It also notes the return value. This is thorough behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although long, the description is well-structured with sections for semantics, exclusions, examples, and parent-moving. Every sentence adds value, and the most critical guidance (merge semantics and sub-resource exclusion) is front-loaded. The examples are illustrative without being redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description is highly complete. It covers what the tool does, what it cannot do, how to handle structured fields, how to reparent, and what the return value is. The presence of an output schema means return details need no further elaboration.
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 fully compensates. It defines entity_url as the self-href URL and changes as a JSON object mapping field names to new values, with concrete examples for single-field, multi-field, structured, and _links-based updates. This gives an agent everything needed to construct valid parameters.
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 operation: 'Update one or more fields on an entity using merge PATCH.' It distinguishes itself from create/delete/get siblings by focusing on partial updates and explicitly excludes sub-resource creation. The phrase 'only the specified fields are sent' adds precise scope.
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?
Usage guidance is explicit and actionable. It says this tool does NOT work for [0..*] or [1..*] sub-resources like 'forfatter' or 'noekkelord' and directs the agent to use noark5_create_secondary_entity instead. It also explains how to move an entity to a new parent using _links and references noark5_list_parents or noark5_entity_links.
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:

[![noark5-tg-mcp MCP server](https://glama.ai/mcp/servers/petterreinholdtsen/noark5-tg-mcp/badges/card.svg)](https://glama.ai/mcp/servers/petterreinholdtsen/noark5-tg-mcp)

Score Badge

Copy to your README.md:

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

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