aas-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools are clearly distinct, but update_submodel_element can also create elements, overlapping with create_submodel_element. Additionally, get_health_status and is_healthy serve similar purposes, which could cause confusion.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern, with plural forms for list operations (e.g., get_shells, get_submodels) and singular forms for specific items. The naming is predictable and uniform across the entire set.
Tool Count3/5
With 25 tools, the server sits at the high end of the acceptable range. The domain is broad, but the count feels heavy, especially with multiple variants for value, metadata, and elements.
Completeness4/5
The tool set covers CRUD for all main resources: shells, submodels, submodel elements, and submodel references. Minor gaps exist, such as lacking an update operation for submodel references and metadata access for elements, but core workflows are well supported.
Average 3.6/5 across 25 of 25 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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, the description must disclose behavioral traits, but it only states the action and HTTP method. It doesn't mention that PUT implies full replacement, potential destructive overwrite, or what the response contains.
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 only two sentences, containing the action and the endpoint mapping. No redundant information.
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 and no output schema, the agent lacks information about return values, error cases, and whether this is a full replacement. The description is too sparse for a mutation tool with nested object parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all four parameters, so the schema handles parameter semantics. The description adds no additional parameter context beyond aligning submodel_id with the update target.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Updates') and resource ('Submodel') with ID scoping, making the core action clear. However, it doesn't distinguish from sibling update tools like update_submodel_value, so some ambiguity remains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over create_submodel or update_submodel_value. The description only states the action without context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the creation action and the endpoint, but does not mention idempotency, error behavior, authentication requirements, or what the response contains.
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 appropriately concise and front-loaded, with the core action stated first. The API endpoint note is useful, though it is the only extra detail and could be integrated more elegantly.
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?
Despite having an output schema, the description lacks essential context for a creation tool with no annotations. It does not cover expected behavior on duplicate, required field details, or lifecycle implications, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema's own field descriptions; it simply names the operation and endpoint.
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 function: 'Creates a new Submodel on the AAS server.' It uses a specific verb and resource, and the resource differs from siblings like create_submodel_ref and create_submodel_element, making it distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The only additional information is the API endpoint ('POST /submodels'), which does not explain use cases, prerequisites, or exclusions.
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?
Because no annotations are provided, the description must carry the burden of behavioral disclosure. It only states 'Check health status' without indicating what the operation returns (beyond output schema), whether it is read-only (obvious but not stated), or how it differs from 'is_healthy' in behavior (e.g., granularity of results).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key action and resource. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with full schema coverage and an output schema, so the description could be minimal. However, the existence of the sibling 'is_healthy' introduces ambiguity that the description fails to resolve, making the tool incomplete in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions for both 'host' and 'timeout'. The description adds nothing beyond the schema, so it meets the baseline for parameter semantics but does not enrich them further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('health status of the AAS environment'), clearly stating the tool's function. However, it does not distinguish itself from the sibling tool 'is_healthy', which likely serves a similar purpose but with a different return type or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like 'is_healthy'. It lacks any mention of prerequisites, context, or exclusions, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight for behavioral disclosure. It merely states 'Deletes' without explaining irreversible effects, required permissions, error behavior, or whether deletion cascades. The raw HTTP endpoint hint is useful but does not compensate for the missing 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 two sentences and includes only the essential operation and endpoint mapping. No filler or redundancy, earning a top score.
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, no output schema, and the existence of many sibling delete and submodel-element tools, the description is too thin. It omits response format, failure modes, idempotency, and any relation to the broader API. The endpoint mapping is useful, but for a deletion operation, more context is needed.
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 100% description coverage, so parameters are already documented. The description adds the endpoint template that highlights the role of submodel_id and id_short_path, but this is minimal extra meaning beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deletes') and the specific resource ('a specific Submodel element') with a precise locator ('by its idShort path'). It also provides the corresponding HTTP endpoint, removing ambiguity and distinguishing it from sibling delete tools like delete_submodel or delete_shell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It only maps to an HTTP DELETE method, which is implicit. There is no mention of prerequisites, scenarios, or reasons to avoid this tool (e.g., if a ref deletion is needed instead).
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 discloses only that a Shell is created via POST, with no mention of idempotency, authorization, duplicate handling, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action. The HTTP endpoint reference is useful context and earns its place without unnecessary verbosity.
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?
With an output schema present and simple parameters, the description does not need to explain return values. However, the lack of behavioral and usage guidance leaves it minimally complete rather than fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'host' and 'shell' documented. The description adds no extra parameter meaning, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a new Shell on the AAS server' with a specific verb and resource. The HTTP endpoint reference (POST /shells) further distinguishes it from sibling tools like update_shell or get_shell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It simply states the creation action without mentioning exclusions or preferred contexts, unlike tools that explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action ('Deletes') and the HTTP method (DELETE), but it does not mention irreversibility, cascading effects on submodel elements, permissions required, or response behavior (e.g., 204 vs error). This is minimal transparency for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that front-load the action and resource. The HTTP endpoint is redundant but harmless. There is zero fluff, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete-by-ID tool with no output schema, the description covers the essential action and endpoint. However, it omits any note about side effects, return values, or the role of the 'encode' parameter in the URL, which would help an agent use it correctly. Adequate but not 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 100% description coverage; all three parameters (host, encode, submodel_id) are already fully described in the schema. The description adds no additional parameter context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deletes'), the resource ('a specific Submodel'), and the identifier ('by its ID'). It also maps to the HTTP DELETE endpoint, leaving no ambiguity about what the tool does and distinguishing it from siblings like delete_submodel_ref.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as delete_submodel_ref or delete_shell. It only describes the operation itself without stating prerequisites, typical use cases, or exclusions, leaving the agent to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states 'Retrieves' and maps to a GET endpoint, which implies read-only behavior, but it does not disclose not-found behavior, permission requirements, or how Base64 encoding affects the request.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and resource, and the endpoint mapping is useful. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has complete schema coverage, and an output schema. However, the lack of usage guidance and behavioral context (e.g., errors, permissions) leaves the description minimally viable rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds the 'by ID' context but does not enrich host or encode behavior beyond what the schema already provides.
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 retrieves a specific Shell by its ID, with a specific verb, resource, and scope. This distinguishes it from siblings like get_shells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_shells. The word 'specific' implies single-item retrieval, but no explicit when-to-use or when-not-to-use context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It only says 'Retrieves' and gives the endpoint, omitting the significant default behavior that submodel_id is Base64-encoded (as revealed by the 'encode' parameter default in the schema). No side effects, authentication needs, or potential error conditions are mentioned.
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 exceptionally concise and front-loaded: a single action-oriented sentence followed by the corresponding endpoint. Every word contributes to understanding the tool's core purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and fully described parameters, the description is minimally complete for a simple retrieval tool. However, the lack of guidance on when to prefer this over sibling tools and the absence of any mention of the encoding behavior leave gaps. The description does not fully prepare an agent to handle the encode default or to distinguish value retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal semantic value beyond the schema; it reuses the term 'idShort path' but does not explain parameter relationships or encode behavior. It correctly implies that submodel_id and id_short_path are the core identifiers, but adds no new meaning.
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 'Retrieves a specific Submodel element by its idShort path,' identifying the verb, resource, and scoping mechanism. It distinguishes from sibling tools like get_submodel_elements (plural) and get_submodel_element_value (value-only retrieval) by emphasizing the element object and path-based lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is provided. The description does not state when to use this tool versus alternatives such as get_submodel_elements or get_submodel_element_value, nor does it mention any prerequisites or conditions. The endpoint reference is informative but does not clarify selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only health check but does not explicitly state side-effect freedom, what 'ready' means, or what happens in failure cases. It provides minimal context beyond the core behavior, which is a clear but sparse 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?
The description is a single, front-loaded sentence that accurately conveys the tool's purpose with zero wasted words. It is appropriately sized for a simple health check operation.
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 tool with a full output schema and 100% parameter coverage, the description is minimally sufficient. However, it lacks differentiation from the sibling 'get_health_status' and offers no usage context, leaving some ambiguity about when to use this tool. This prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with descriptions, so the baseline is 3. The description adds no additional parameter-level meaning beyond what the schema already provides, which is acceptable given the high 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 function: 'Check if the AAS environment is ready for requests.' It uses a specific verb and resource, making the purpose obvious. However, it does not differentiate from the sibling tool 'get_health_status', which likely serves a similar role, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_health_status'. There is no mention of scenarios where this check is appropriate, prerequisites, or exclusions. The agent is left to infer the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the HTTP method (PATCH) but does not explain whether the update is a full replacement or partial, what happens to missing submodels, authentication requirements, or any side effects. This is significant for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with no fluff. The first sentence conveys the core purpose, and the second provides the corresponding endpoint, which is useful context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and endpoint, but it lacks context about when to use the tool, what response to expect (no output schema exists), and how it relates to similar update tools. It is adequate for a simple operation but misses completeness in terms of usage and return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are described in the schema. The description adds no additional parameter meaning beyond the schema, which is acceptable but not enhanced. The baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Updates the value') and the resource ('a specific Submodel'), and the endpoint reference distinguishes it from sibling tools like update_submodel. It is specific and 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?
No guidance is provided on when to use this tool versus alternatives like update_submodel or update_submodel_element_value. The description only states what it does, not the selection criteria or exclusions, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It states the action but does not disclose whether the deletion is permanent, what happens if the reference does not exist, or whether the submodel itself is affected. No side effects, error conditions, or authorization requirements are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and a useful HTTP endpoint reference. No redundant information or filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with a fully described schema and an explicit HTTP mapping, the description is largely complete. It distinguishes 'reference' from the actual submodel, and the schema covers the parameters. However, it could be slightly more complete by noting that the underlying submodel is not deleted, but this is reasonably implied by 'reference' and the sibling tool 'delete_submodel'.
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 provides descriptions for all parameters (100% coverage), so the baseline is 3. The description adds the HTTP endpoint mapping, which indirectly clarifies how shell_id and submodel_id are used, but it does not add significant new meaning beyond the schema's parameter descriptions. Host and encode are already adequately described 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 clearly states the action ('Deletes a specific submodel reference') and the target resource ('from a Shell'), and the HTTP endpoint further distinguishes it from sibling tools like delete_submodel. It is specific and unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as delete_submodel or create_submodel_ref. It lacks any context about prerequisites, when not to use, or which scenarios call for this operation. The only hint is the implicit differentiation in the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavioral traits. It only states that it deletes a shell and gives the HTTP method, but does not mention permanence, cascading effects, permissions required, or any side effects. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and followed by the HTTP mapping. Every sentence earns its place with no unnecessary detail.
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 delete operation with a full schema, the description is adequate but not complete. It does not explain the return behavior (e.g., HTTP status codes), nor does it mention the 'encode' parameter's purpose beyond the schema. Given the lack of output schema and annotations, a bit more context would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it mentions 'by its ID' which aligns with shell_id, but does not explain the host or encode parameters. The schema already documents these adequately.
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 'Deletes a specific Shell by its ID' with a specific verb and resource, and the HTTP mapping further reinforces the exact action. This distinguishes it from siblings like get_shell, create_shell, and update_shell.
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: if you need to delete a shell, use this tool. However, it does not provide explicit when/when-not guidance or mention alternatives, and it lacks any mention of prerequisites or conditions such as whether associated resources must be removed 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, the description must carry the behavioral disclosure burden. It does so by stating 'full replacement', which warns that any existing element at the path will be overwritten, and the 'Updates or creates' phrase implies an upsert behavior. However, it does not mention permissions, error scenarios, or what happens to omitted fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first line states the action and resource, the second gives the HTTP mapping. No superfluous words 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 write tool with no annotations and no output schema, the description explains the core replacement behavior and endpoint but does not mention return value, error handling, or response format. The schema covers parameters well, so the description is adequate but not fully complete for a 5-parameter tool with a nested object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the schema descriptions cover all parameters. The description adds context about 'element' being the new content and maps the path via the endpoint, but does not add syntax or format details beyond what the schema already provides. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Updates or creates') and the resource ('Submodel element') with a specific mechanism ('by full replacement'). This distinguishes it from related tools like update_submodel_element_value, which only updates the value, not the whole element.
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 does not explicitly tell when to use this tool versus alternatives such as create_submodel_element or update_submodel_element_value. It mentions 'updates or creates' but does not explain when one would prefer the dedicated create tool or when this is the right choice over the value-only update tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation via 'Retrieves' and the corresponding GET endpoint, which is useful behavioral context. However, with no annotations provided, it does not disclose error handling, authentication requirements, or the exact structure of the returned metadata beyond what the output schema might cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the action and target, the second provides the corresponding HTTP endpoint. Every word contributes value.
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 simplicity of the tool, complete schema coverage, and presence of an output schema, the description provides sufficient context for an agent to understand the tool's purpose. However, it lacks explicit sibling differentiation, which prevents a perfect score.
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 100% coverage for all three parameters, so the description does not need to add parameter details. The description adds no additional meaning beyond the schema, which is acceptable given the baseline.
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 retrieves metadata for a specific Submodel, using a specific verb and resource. The 'Corresponds to GET /submodels/{submodel_id}/$metadata' further clarifies the exact operation and distinguishes it from the sibling get_submodel which retrieves the full submodel rather than its metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like get_submodel or get_submodel_value. The description implies its purpose but does not state usage context 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 clearly indicates a read-only operation ('retrieves') and gives the HTTP endpoint, but it does not disclose error behavior, authentication needs, or any side effects. While 'retrieves' implies non-mutating, more context about response or failure modes would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no redundant information. The first sentence states the purpose, and the second provides the corresponding HTTP endpoint, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET operation with an output schema present, the description is sufficiently complete. It specifies the exact endpoint and action. It could mention that the shell must exist or that only refs (not full submodels) are returned, but these are minor gaps given the schema and endpoint clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the schema already fully explains their meanings. The description adds no additional parameter-specific semantics, aligning with the baseline score of 3 when schema coverage is high.
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 it retrieves all submodel references from a specific Shell, using the specific verb 'retrieves' and a precise resource. This distinguishes it from sibling tools like get_submodel (which gets a single submodel) and create_submodel_ref (which creates a ref).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description merely states the action and HTTP endpoint without noting exclusions or recommending when to choose this over get_submodel or get_submodel_refs. The HTTP endpoint is useful but does not constitute usage guidance.
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 burden. It indicates a read operation through 'retrieves' and the GET endpoint, but provides no additional behavioral details such as error behavior or side effects. It is minimally sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the main action first and the endpoint as clarification. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description clearly identifies the tool's purpose and the technical endpoint. The output schema covers return values, and the param schema covers inputs. However, it does not explicitly differentiate from sibling tools like get_submodel, so it's slightly incomplete for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already contains full descriptions for all three parameters (100% coverage), and the description adds no parameter information beyond that. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieves' and the resource 'raw value of a specific Submodel', and the endpoint reference distinguishes it from the sibling get_submodel which likely returns full model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over get_submodel or get_submodel_element_value. The description does not include any usage context or exclusions.
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 responsibility for behavioral disclosure. It only states that a reference is created and maps to a POST endpoint; it does not mention side effects, prerequisites (e.g., Shell must exist), idempotency, duplicate handling, or what the response will be.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that state the purpose and the corresponding REST endpoint. It contains no filler or redundant information and is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and target resource but is minimal for a create operation with no annotations and no output schema. It does not explain behavior on error conditions, duplicate references, or whether the submodel itself must already exist, which leaves some ambiguity for a fully autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with shell_id and submodel_ref both described in the input schema. The tool description adds no extra parameter meaning beyond the endpoint path, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Creates a submodel reference') and identifies the target resource ('for a specific Shell'). It distinguishes this tool from siblings like create_submodel (which creates the submodel itself) and delete_submodel_ref (which removes a reference).
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 that this tool is for adding a submodel reference to a Shell, and the HTTP endpoint mapping reinforces its purpose. It does not explicitly state when not to use it or mention alternatives like create_submodel, but the resource-specific wording makes the intended use unambiguous.
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 must disclose behavioral traits. It only says 'Updates' and the HTTP method, but does not state whether it is a full replacement, error behavior, or authentication needs. This is a gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The HTTP endpoint mapping adds useful context without 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?
The schema fully documents parameters, but without annotations or output schema, the description should explain PUT semantics and error conditions. It is minimally adequate but lacks behavioral depth for an agent to fully predict side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are described in the schema (100% coverage), so the description adds no additional parameter semantics. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: updates an existing Shell by ID. Distinguished from create_shell/delete_shell by the explicit 'Updates an existing' phrasing and the PUT mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for existing shells, not creation, which differentiates it from create_shell. However, no explicit alternates or when-not-to-use guidance is provided.
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 behavioral disclosure burden. It states 'GET /shells', which implies a read-only operation, and 'Retrieves all Shells' confirms the general behavior. However, it does not disclose potential edge cases such as empty results, authentication requirements, or query limitations. For a simple list operation, the basic read-only nature is evident, but richer context is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the core functionality and adds the HTTP endpoint for technical clarity. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and a well-documented parameter, the description is largely sufficient. It explains what is returned (all Shells) and the operation type. It does not need to detail return structure since the output schema exists. It falls short of 5 only because it lacks explicit usage guidance relative to sibling tools.
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 100% description coverage for the only parameter 'host', providing a default and explanation. The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Retrieves all Shells from the AAS server.' It uses a specific verb (Retrieves), a specific resource (all Shells), and server context (AAS). The phrase 'all Shells' distinguishes it from sibling get_shell, and the HTTP mapping 'GET /shells' adds unambiguous precision.
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 (use when you need all Shells) but does not explicitly exclude alternatives or mention when not to use it. It lacks direct comparison to get_shell for single-shell retrieval. The guidance is mostly inferred from the resource name and HTTP endpoint, not explicitly 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?
With no annotations, the description carries the full burden. It discloses the HTTP method (GET) and the 'raw value' semantics, but it does not mention potential pitfalls like binary responses, encoding behavior, or error conditions. The $value path hint adds some transparency but not rich detail.
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 extremely compact: one sentence stating purpose and one line for the endpoint. No wasted words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with an output schema and complete parameter documentation, the description is largely sufficient. It lacks explicit usage guidance, but the endpoint mapping provides enough context to understand its role among sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are already described in the schema. The description references submodel_id and id_short_path in the endpoint but adds no extra meaning beyond the schema. Since the schema does the heavy lifting, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the raw value of a specific Submodel element, using a precise verb and resource. It distinguishes itself from siblings like get_submodel_element (which returns metadata) by referencing the $value endpoint, making its scope unambiguous.
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 REST endpoint implies when to use this tool (to get raw values without metadata), but it does not explicitly compare with alternatives like get_submodel_value or get_submodel_element. Usage is inferable but not directly stated, so it falls at the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the HTTP method (GET) via the endpoint, implying a read-only, idempotent operation. However, it does not mention authentication requirements, pagination, or potential performance implications of retrieving all elements, so transparency is minimal but present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the purpose, the second maps it to the exact REST endpoint. It is front-loaded with the action and resource, contains no filler, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, a single-purpose retrieval operation with 3 parameters and an output schema, the description is largely complete. It provides the purpose and API mapping. However, it lacks any usage guidance or cautionary notes, so it is not fully comprehensive, but sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond the schema; it only includes submodel_id in the endpoint path, which is already described in the schema. The tool description adds no extra semantic value for 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 uses the specific verb 'Retrieves' and clearly identifies the resource as 'all Submodel elements from a specific Submodel'. It distinguishes from siblings like get_submodel (the Submodel itself) and get_submodel_element (a single element) by explicitly stating 'all'. The corresponding REST endpoint adds further precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you need to retrieve all elements of a specific Submodel. It does not explicitly mention alternatives or exclusions, but the scope is unambiguous and the sibling context (get_submodel_element for a single element) makes the usage context 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?
There are no annotations, so the description must carry the behavioral disclosure burden. It discloses the HTTP method and path, showing that it performs a partial update of the value property. However, it does not mention permissions, side effects, or error behavior, leaving gaps typical of mutation tools without annotations.
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 highly concise with two sentences: the first states the action, and the second gives the REST mapping. There is no filler or redundancy, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and potentially confusing sibling tools, the description anchors the operation precisely via the HTTP endpoint. It lacks explicit return value or error information, but the purpose and differentiation are sufficient for basic usage. Some additional guidance on exclusions would make it complete, but it is not inadequate.
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 100% coverage with each of the 5 parameters described, so the baseline is 3. The tool description adds no extra parameter information beyond what the schema already provides, but the schema is sufficient on its own.
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 updates the value of a Submodel element, using the verb 'Updates' and specifying the exact resource. The REST endpoint PATCH /submodels/{submodel_id}/submodel-elements/{id_short_path}/$value distinguishes it from sibling tools like update_submodel_element, which likely updates element metadata rather than just the value.
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 the specific REST endpoint, indicating this tool is for value-only updates of a Submodel element. This gives clear context on when to use it, though it does not explicitly exclude alternatives or name sibling tools such as get_submodel_element_value or update_submodel_element.
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, and it discloses the read-only HTTP GET behavior via 'Corresponds to GET /submodels' and the 'all' scope, indicating no filtering. It does not detail auth needs or pagination, but these are less critical for a simple read operation and the output schema covers return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, and the endpoint mapping is provided in a clear, compact format. Every word earns its place.
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 simple one-parameter schema, the presence of an output schema for return values, and the clear endpoint mapping, the description is complete enough for an agent to select and invoke the tool correctly. No crucial behavioral or contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'host' parameter, which already includes a description and default. The tool description adds no extra semantic value beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieves all Submodels from the AAS server' with a specific verb, resource, and scope. The endpoint 'GET /submodels' reinforces the exact operation, distinguishing it from singular get_submodel and reference-focused get_submodel_refs.
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 for retrieving all submodels but does not explicitly state when to prefer it over alternatives like get_submodel or get_submodel_refs. No exclusions or alternative comparisons are provided.
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 transparency burden. It discloses the key nested-path vs root behavior, but lacks details on idempotency, error handling, element structure requirements, or response format. For a mutation tool, this leaves some behavioral 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 succinct and front-loaded with the main verb+object. It uses a clear conditional and includes only relevant endpoint information. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The combination of the schema and description covers all parameters and explains the unique nested path behavior. However, with no output schema or annotations, the description does not mention return values or potential errors. For an AAS API, it is reasonably complete given the schema's richness.
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 covers all parameters, and the description adds meaning to id_short_path by explaining its effect on the creation location. It also maps parameters to the HTTP endpoints. The 'element' parameter remains abstract, but the schema provides an adequate description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a Submodel element' with a specific verb and resource. It distinguishes behavior based on id_short_path, separating it from siblings like create_submodel or update_submodel_element. The HTTP mapping further clarifies the exact endpoints.
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 implies when to use the tool by explaining the action and the two path scenarios, but it does not explicitly mention alternatives or when not to use it. The sibling names provide context, but no explicit exclusions are given.
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 safety disclosure. It explicitly states 'GET /submodels/{submodel_id}', clearly indicating a read-only, side-effect-free operation. It does not mention the base64 encoding behavior or error cases, but the HTTP method provides a solid transparency baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and resource, followed by a concise HTTP endpoint. Every word earns its place, with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with an output schema, the description is sufficient. It explains the core purpose and endpoint. However, it does not explicitly differentiate from near siblings like get_submodel_value or get_submodel_metadata, which slightly limits contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all three parameters (host, encode, submodel_id). The tool description itself adds no additional parameter semantics beyond what the schema already documents, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieves a specific Submodel by its ID,' using a specific verb and resource, and also provides the HTTP endpoint. This distinguishes it from siblings like get_submodels (plural), get_submodel_value, and get_submodel_metadata.
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 implies usage when a specific submodel ID is known, reinforced by the GET endpoint. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select this tool for retrieving a single submodel.
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:

[![aas-mcp MCP server](https://glama.ai/mcp/servers/SmartFactory-KL/aas-mcp/badges/card.svg)](https://glama.ai/mcp/servers/SmartFactory-KL/aas-mcp)

Score Badge

Copy to your README.md:

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

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