mmar-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool targets a distinct resource-action pair, with detailed descriptions that differentiate even similar operations like getting the 'from' vs 'to' role of a relationclass instance. There is no ambiguity between tools.
Naming Consistency5/5
All tools follow a consistent `mmar_` prefix with snake_case verb_noun naming (e.g., `mmar_create_class`, `mmar_get_scene_instance`). Verbs are used predictably: `list` for collections, `get` for individual items, and `create`/`update`/`delete` for mutations.
Tool Count2/5
62 tools is far beyond the typical MCP scope, making the surface unwieldy. While the domain is complex, the count is excessive and could likely be consolidated by grouping related operations or using parameterized actions.
Completeness3/5
The tool set covers most CRUD operations for both metamodel and instance levels, but notable gaps exist: there is no way to delete a meta-attribute, a role, or a port. These missing operations could hinder agents trying to fully modify a metamodel.
Average 3.9/5 across 62 of 62 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on July 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It clearly indicates a read operation ('Get') but does not disclose what 'full details' includes, error handling, or authentication requirements. As a getter, mutation risk is low, but the lack of any behavioral context limits 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 two sentences, front-loaded with the action and resource, followed by a helpful domain clarification. No redundant information or filler; every sentence 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 tool is a simple getter with one parameter and no output schema. The description explains the purpose and domain concept, but does not specify return structure, error behavior, or authentication context. Given the absence of annotations and output schema, a more complete description would mention these aspects, so it is minimally viable.
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 fully documents the uuid parameter with a description and format. The description simply restates 'by UUID' without adding additional semantics. Given the high schema description coverage (100%), the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the full details'), the resource ('a specific port'), and the lookup method ('by UUID'). It also adds domain context ('Ports are connection points on classes'). While it doesn't explicitly compare to sibling getters, the resource name inherently differentiates it from other get_* tools.
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 you need a UUID to retrieve a port, but does not provide explicit guidance on when to use this tool versus alternatives. No prerequisites like authentication (implied by sibling login tools) or exclusions are mentioned. The usage context is only implied by 'by UUID'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and target, without mentioning prerequisites like a valid scene instance, data format validation, side effects, return values, or error behavior. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the action. There is no unnecessary wording or repetition of schema details.
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 description is too sparse to fully inform an agent. It does not explain the structure or requirements of port_instance_data, the prerequisite of an existing scene instance, or the outcome of the creation. A more descriptive explanation is needed for this creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters (scene_instance_uuid and port_instance_data), covering 100% of the parameters. The description adds no additional parameter-level meaning beyond implying the scene instance is the container. With this high schema coverage, 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 uses a specific verb 'Create' and a specific resource 'port instance' with the context 'within a scene instance,' clearly distinguishing this from sibling tools like mmar_create_port or mmar_create_class_instance. It is unambiguous what action is performed and where.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to create a port instance inside an existing scene instance, but it does not explicitly state when to use this over alternatives (e.g., mmar_create_port) or provide any exclusions. The usage context is implied rather than directly guided.
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 operation without noting that deletion is permanent, whether it requires existing instance checks, or what happens to related data. A delete operation typically warrants more caution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the verb and resource. There is no redundant information or filler.
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 the simple one-parameter schema, the tool is a destructive DELETE operation with no annotations or output schema. The description fails to mention irreversibility, potential side effects, or any required authorization, leaving important context missing.
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 the single 'uuid' parameter, which already explains it as 'The UUID of the AttributeInstance to delete'. The description does not add any additional meaning beyond the schema, aligning with the baseline of 3.
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 (Delete), the resource (attribute instance), and the identifier (by its UUID). It is specific and distinguishes from sibling delete tools by naming 'attribute instance' rather than just 'instance'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and description: it is used to delete a specific attribute instance. However, there is no explicit guidance on when to use this versus other delete tools or when not to use it, nor any mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It does not specify whether the update is partial or full replacement, what happens if the attribute does not exist, side effects, or any permissions needed. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main action. It is concise and free of unnecessary words, though it could be improved with structured formatting for the list of fields. Still, it is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter update tool with full schema coverage, the description is minimally adequate: it states purpose and payload fields. However, it lacks essential behavioral context such as partial vs. full replacement, error handling, or return value expectations, leaving an agent uncertain about the update semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters, giving a baseline of 3. The description adds value by listing the expected fields inside the 'attribute_data' JSON (name, default_value, sequence, ui_component, attribute_type), which clarifies what the JSON string should contain beyond the schema's generic wording.
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 ('Update an existing meta-attribute') with a specific verb and resource. It distinguishes from creation tools by emphasizing 'existing' and lists the key fields to update. This leaves no ambiguity 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?
No explicit when-to-use or alternatives are provided. The description implies use for updating an existing attribute but does not contrast with create_attribute_for_class or other related tools, nor does it mention prerequisites or contexts where this tool is preferable.
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 does disclose input requirements (attribute_data must include certain fields, and attribute_type must reference an existing AttributeType), but it omits behavioral details such as session/auth needs, failure modes, return value, or any side effects beyond creating an attribute. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, the second lists the required data fields. It is front-loaded, with no filler, and every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter create tool, the description plus schema covers the required inputs and the existence of the AttributeType. However, there is no output schema, no mention of return value, error handling, or session requirements. The description is adequate but has clear gaps around the full context of 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 schema fully documents both parameters. The description mostly repeats the schema's attribute_data structure, adding only the clarification that the attribute_type must reference an existing AttributeType. This adds marginal value over the schema, 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 opens with a specific verb+resource: 'Add a new attribute to an existing class.' This clearly states what the tool does and differentiates it from the sibling mmar_create_attribute_for_scene_type by explicitly targeting existing classes.
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 'to an existing class' implies the intended use case, but there is no explicit guidance on when to use this tool versus alternatives like mmar_create_attribute_for_scene_type. No exclusions or alternative references are provided, so usage context is only implied by the purpose statement.
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 carry the full burden of behavioral disclosure. It only states that it creates a bendpoint, but does not mention side effects, validation, session requirements, or the return value. For a creation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action in the first sentence, and contains no unnecessary words. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but covers the core purpose. Given no annotations and no output schema, it lacks context about prerequisites (e.g., existing relationclass instance, session) and constraints (e.g., bendpoint sequence uniqueness). For a simple tool with 2 params, it is 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 provides descriptions for both parameters (100% coverage), so the description does not need to add much. The tool description does not add parameter-specific details beyond the schema, but the schema's descriptions are clear, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the target ('bendpoint'), the component ('relationclass instance'), and the rationale ('add waypoints to the connection line for routing'). It distinguishes from sibling tools like mmar_update_bendpoint and mmar_delete_bendpoint.
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 adding waypoints but does not explicitly mention when to use it vs alternatives like update or delete, nor does it state prerequisites or exclusions. The phrase 'add waypoints' provides an implied use case, but there is no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It simply states the delete action without mentioning irreversibility, potential cascading effects, permission requirements, 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 a single, focused sentence that immediately states the action and target. It is front-loaded and contains no filler, making it easy for an agent to process quickly.
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 one-parameter delete tool, the description is minimally viable. However, it lacks information about return values (e.g., success/failure indication) and potential error conditions (e.g., UUID not found), which would be helpful for an agent to fully anticipate the tool's behavior. The absence of an output schema shifts more responsibility onto the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'uuid' parameter as 'The UUID of the Bendpoint to delete' with 100% coverage. The description's mention of 'by its UUID' adds no new semantics beyond what the schema provides, so 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 ('Delete'), the resource ('bendpoint'), and the identifier ('UUID'). It distinguishes itself from sibling tools like create_bendpoint and update_bendpoint by using the exact resource type.
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 usage is implied by the operation name and description—users will call this when they need to delete a specific bendpoint by its UUID. However, there is no explicit guidance about when to use this tool vs alternatives (e.g., update vs. delete), or any prerequisites like having a valid connection.
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 carry the full burden of behavioral disclosure. It only says 'Get', implying a read operation, but does not disclose what happens if the relationclass instance does not exist, whether an empty list is returned, authentication requirements, or any side effects. The description adds minimal behavioral context beyond the tool 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 a single, clear sentence that conveys the essential information without any unnecessary words, repetition, or boilerplate. It is concise and front-loaded.
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 get tool with one parameter and no output schema, the description adequately conveys what it does and the return concept ('all attribute instances'). However, it lacks any mention of failure modes, prerequisites (e.g., the relationclass instance must exist), or any behavioral context that would be important for an agent, especially given the absence of annotations and output schema. Thus, it is minimally viable but with clear gaps.
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 a single parameter relationclass_instance_uuid described as 'The UUID of the RelationclassInstance'. The description adds no extra meaning about the parameter format or usage beyond what the schema already provides, 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 gets all attribute instances for a specific relationclass instance, with 'connection' in parentheses clarifying the domain term. This distinguishes it from the sibling tool mmar_get_attribute_instances_for_class_instance, making the 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: you need a relationclass_instance_uuid to retrieve attribute instances. However, it does not explicitly state when to use this tool versus alternatives (e.g., mmar_get_attribute_instances_for_class_instance) or provide any exclusions. The usage guidance is implied rather than explicit.
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 present, the description carries full responsibility for behavioral disclosure. It only states the read action ('Get') without describing return format, pagination, potential errors, or any side effects. This is a minimal disclosure that adds little beyond the tool's basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is front-loaded with the verb and resource. Every word earns its place, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimal but adequate for basic calling. However, it does not explain what a port instance is or what the response structure looks like, which could be useful for an AI agent. The lack of output schema means the description is the only source for return expectations.
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 fully describes the single parameter (scene_instance_uuid with a clear description), providing 100% coverage. The tool description adds no additional meaning beyond the schema, 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 uses a specific verb 'Get' and names the resource 'port instances' with a clear scope ('within a specific scene instance'). This distinguishes it from sibling tools like mmar_get_port_instance, which fetches a single port instance. The purpose is unambiguous and complete.
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 (when you need all port instances for a scene instance) but provides no explicit guidance on when to use this tool versus alternatives such as mmar_get_port_instance. It does not mention exclusions or refer to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It says 'Get the full details', which implies a read operation, but does not explicitly state that it's read-only, whether an active session is required, or any potential side effects. It also does not clarify the return structure beyond 'full details'.
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 clearly states the tool's purpose and key selection criterion. Every word is necessary and there is no redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no nested objects, no output schema), the description covers the basic action. However, 'full details' is vague and does not specify what is included, such as attributes, roles, or other related data. Since there is no output schema, the description could benefit from elaborating on the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the parameter 'uuid' described as 'The UUID of the RelationclassInstance to retrieve'. The description simply references 'UUID' without adding new meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'full details of a specific relationclass instance', and specifies the selection mechanism 'by its UUID'. It distinguishes from sibling tools like mmar_get_relationclass_instances (plural) and mmar_get_relationclass (type definition) by emphasizing 'specific' and 'connection/edge'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you have a UUID of a relationclass instance and need its full details. However, it does not explicitly mention when not to use it, such as for listing all instances (use mmar_get_relationclass_instances) or for retrieving the relationclass type definition (use mmar_get_relationclass).
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 for behavioral disclosure. It states the update action but does not mention side effects, permission requirements, reversibility, or expected response behavior—similar to the update_drive calibration example.
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 compact two-sentence summary with no redundant wording. The action verb leads, and the additional sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers parameters well, but the description omits any mention of return values or error behavior. Given no output schema and no annotations, this is a mild gap.
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 covers 100% of the parameters with clear descriptions, so the baseline is 3. The description adds little beyond the schema, though 'change the waypoint position' hints at the content of bendpoint_data.
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 ('Update an existing bendpoint') and resource, distinguishing it from sibling create/delete bendpoint tools. Adding 'change the waypoint position' further specifies the exact purpose.
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 'Use this to change the waypoint position' gives a clear context for when to use the tool, but it does not explicitly mention alternatives (e.g., create_bendpoint, delete_bendpoint) 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'check' suggests a read-only operation, the description does not explicitly confirm that it has no side effects, nor does it state what the tool returns (e.g., a boolean or session object). This leaves important behavioral details unspecified.
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 states the core function and provides a parenthetical clarification. Every word earns its place, with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (zero parameters, no output schema), but the description does not disclose the return format or behavior, which the agent would need to interpret the result. Since there is no output schema to fall back on, the description should have mentioned what a 'check' returns, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema provides no semantics to clarify. According to the baseline for zero-parameter tools, a score of 4 is appropriate; the description does not need to explain parameters that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('active MM-AR session'), and clarifies the meaning ('user is currently logged in'). It is easily distinguished from sibling tools like mmar_login and mmar_logout, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to verify login status, but it does not explicitly state when to use it in a workflow (e.g., before other operations) or compare it to alternatives. No exclusions or alternative tools are mentioned, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Add' (a mutation) and notes 'Same structure as class attributes,' but it does not mention permissions, validation, duplicate handling, or whether the operation is reversible. This is insufficient for a create operation without annotation support.
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 verb, and contains no unnecessary words. The parenthetical clarification and structural reference are concise and meaningful, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should provide more context about return values, errors, and prerequisites, but it only mentions the scene type must exist. The gap in behavioral and return information makes the tool under-specified for an agent to fully anticipate the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters with 100% coverage, including the structure of attribute_data. The description adds the context that attribute_data follows the same structure as class attributes, which is useful but not essential. Baseline 3 is appropriate because the schema carries the semantic weight.
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 'Add' and clearly identifies the resource: an attribute to an existing SceneType. The parenthetical 'scene-level attribute, not on a class' effectively distinguishes this tool from the sibling mmar_create_attribute_for_class.
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 parenthetical 'not on a class' provides an explicit exclusion, implying this tool is for scene-level attributes rather than class-level ones. However, it does not name the alternative tool directly, leaving the guidance slightly less explicit than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. It usefully states that deletion includes 'all its contents,' revealing the cascading destructive scope. However, it does not mention permissions, irreversibility, or what happens to related data outside the scene instance, so it is only partially 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 a single, front-loaded sentence with no filler. Every phrase adds value: the action, the resource, the scope, and the lookup key.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter deletion tool whose input is fully documented by the schema. The description adds the critical destructive scope ('all its contents'). It lacks usage guidance and explicit return-behavior information, but neither is essential for a straightforward delete operation.
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 fully documents the only parameter 'uuid' with type, format, and a description ('The UUID of the SceneInstance to delete'). The description adds no additional semantic detail beyond restating 'by UUID,' so the schema does the heavy lifting and a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Delete'), the resource ('specific model instance (diagram)'), the scope ('and all its contents'), and the input mechanism ('by UUID'). This distinguishes it from sibling delete tools like mmar_delete_class_instance or mmar_delete_relationclass_instance.
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, nor any preconditions or exclusions. It only states the mechanism (by UUID), leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explains the semantic content of relationclasses (roles, source/destination rules), which adds useful context. However, it does not explicitly state read-only nature, permissions, or response format, leaving gaps for a getter 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 sentences with no unnecessary detail. It explains both the action and the domain concept succinctly, 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 getter with one parameter and no output schema, the description adequately conveys the return: all relation types for the given SceneType. It also explains what relationclasses are. However, it doesn't mention ordering, pagination, or error conditions, though these are less critical for a straightforward list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents scene_type_uuid with 100% coverage. The description adds a minor clarification ('specific modeling language (SceneType)') but essentially restates the schema. No additional parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('all relation types (edge/connection types)') scoped to a SceneType. It clearly distinguishes from sibling tools like mmar_get_classes_for_scene_type and mmar_get_relationclass by focusing on relation types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are provided. The description only states what the tool does, not when to choose it over other list/getter tools. Usage is implied by the name and parameter but not spelled out.
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 for behavioral transparency. It only states the core action and a definition of a port, but omits prerequisites (e.g., existing class, session), behavior on duplicate or invalid input, side effects, and return value. For a mutation tool, this is a significant gap.
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 action, followed by a helpful definition. No redundancy or fluff. Every sentence 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 tool is relatively simple with two parameters and a helpful schema, but the description omits the return value and any preconditions. Without annotations or an output schema, a bit more context (e.g., what happens on success/failure) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with detailed descriptions for both parameters (uuid and port_data). The description adds conceptual context about ports but no additional parameter-specific guidance. Baseline 3 is appropriate when the schema carries 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 uses a specific verb ('Create') and resource ('port'), clearly stating the target ('on a class'), which distinguishes it from sibling tools like mmar_update_port and mmar_create_port_instance. It also adds a concise definition of a port, removing ambiguity 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this is for creating class-level ports ('on a class'), which helps differentiate from mmar_create_port_instance. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of the highest level of explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It states the delete action but does not disclose side effects such as whether associated attribute instances, role instances, or ports are also deleted, nor whether the operation requires an active session. This leaves the agent without crucial behavioral information 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 a single, clear sentence that gets straight to the point without unnecessary 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?
Given the simple one-parameter interface and no output schema, the description is mostly adequate, but it lacks details on preconditions (e.g., valid session) and post-conditions (cascade deletes), making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the only parameter (uuid) with a description and format. The tool description's 'by its UUID' adds no substantive meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' with the resource 'class instance' and clarifies it as 'element/node', distinguishing it from sibling delete tools such as mmar_delete_class and mmar_delete_relationclass_instance. It also specifies the key identifier 'UUID'.
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 indicates the tool's scope: deleting a specific class instance, which implies it should be used over sibling tools like mmar_delete_class or mmar_delete_scene_instance. However, it does not explicitly mention when not to use it or name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits beyond the basic action. It only states the deletion and gives no information about cascading effects on associated data (e.g., attributes, roles, bendpoints), permission requirements, or idempotency. This is a notable 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 a single sentence that front-loads the verb and object, with no extraneous wording. It is concise and well-structured, clearly stating the action and scope.
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 single-parameter delete operation, the description is minimally viable: it names the resource and the parameter. However, it omits any mention of side effects on related entities (e.g., role instances, attribute instances, bendpoints) which are relevant for a relationclass instance. This gap prevents it from being 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?
The input schema already provides a full description for the uuid parameter, including format and meaning. The description adds no new information beyond what the schema already states, so this meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Delete'), the resource type ('relationclass instance'), and adds a clarifying parenthetical ('connection/edge') that distinguishes it from other instance or class deletion tools. It also states the identifier key ('by its UUID'), 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 for when to use this tool: when deleting a specific relationclass instance by UUID. While it does not explicitly mention alternatives or exclusions, the 'connection/edge' wording and the tool's name imply it is distinct from deleting class instances or relation classes, which is sufficient for simple 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 provided, so the description must carry the full transparency burden. 'Get' implies a read-only operation and 'full details' indicates the return scope, but it does not mention authentication requirements, error behavior, or the structure of the returned details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the action and resource. There is no redundant wording or filler; every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and no output schema, the description is adequate but minimal. It does not mention whether a valid session is required (given sibling tools like mmar_login and mmar_check_session) or what 'full details' includes, leaving some context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single uuid parameter with 100% coverage, so the description adds no new information beyond repeating 'by its UUID'. The schema is sufficient, and the description does not need to compensate for missing parameter 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 'Get' and clearly identifies the resource as 'full details of a specific port instance by its UUID'. It distinguishes from sibling tools like mmar_get_port and mmar_get_port_instances_for_scene_instance by focusing on a single instance identified by UUID.
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 'by its UUID' implies this tool is for retrieving a single known instance rather than listing instances for a scene. However, it does not explicitly mention when to prefer this over alternatives or state any exclusions, leaving usage guidance mostly implicit.
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 the mutation behavior (updating values), but does not mention permissions, reversibility, error handling, or what the return value looks like. This is a thin disclosure for a write 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, with the purpose stated first and a usage clarification second. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and 100% schema coverage, the description is adequate but not rich. It does not explicitly differentiate from mmar_update_attribute, nor does it explain partial vs. full replacement behavior. It is minimally complete but could benefit from a note on how attribute_data is merged.
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 provides 100% coverage, describing both parameters, so the baseline is 3. The description adds examples of what attribute values might be, but does not elaborate on the JSON structure beyond what the schema already states.
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 ('Update') and the resource ('attribute instance'), and explicitly says it changes data values on elements. This distinguishes it from sibling tools like mmar_update_attribute, which likely updates attribute definitions rather than instances.
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 phrase 'Use this to change data values on elements' provides direct usage context, and the examples (name, description, custom attribute) clarify typical use cases. It does not explicitly name alternatives or exclusions, but the 'instance' distinction and context signals make the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and parameter, without mentioning potential side effects (e.g., irreversibility, cascading deletes) or prerequisites (e.g., active session). This is a 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 a single sentence that front-loads the action and target, with no unnecessary words. It is concise and appropriately sized for a simple tool with one parameter.
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 (one parameter, no output schema), the description is mostly complete. It names the action and the parameter, which is sufficient for a basic delete operation. However, it omits any mention of authentication or side effects, which are relevant given the sibling tools, but the simplicity balances this to a 4.
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 covers 100% of the parameter, with a clear description for 'uuid'. The tool description adds no further parameter semantics, so the baseline of 3 is appropriate as the schema already provides the necessary 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 action ('Delete') and the specific resource ('PortInstance') with a precise identifier (UUID). It distinguishes it from sibling delete tools by specifying the entity type, eliminating ambiguity.
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 that this tool should be used when deleting a port instance, and it is clearly distinct from other delete tools based on entity type. However, it does not explicitly provide alternative tools or exclusions, so it does not fully meet the 5-level benchmark.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does describe the return content (regex pattern, name, description), which is helpful. However, it does not mention whether a valid session is required (despite sibling mmar_check_session), error behavior, or that it is a non-mutating read-only operation beyond the verb 'Get' implying so.
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 and 21 words. It front-loads the main action and return value, with no filler, redundant phrases, or unnecessary detail. 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 getter with one parameter and no output schema or annotations, the description covers the core purpose and return content adequately. However, it could add disambiguation from mmar_get_attribute (which may refer to attribute instances) and note session requirements or error cases, making it just short of 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% coverage with the parameter description 'The UUID of the AttributeType to retrieve.' The tool description repeats 'by UUID' and adds return field details, but it does not enrich the parameter meaning further. Baseline 3 is appropriate as the schema already fully documents the parameter.
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+resource: 'Get full details of a specific attribute type by UUID.' It clearly distinguishes this from the sibling mmar_list_attribute_types by emphasizing 'specific' and 'by UUID', and it lists the key return fields (regex validation pattern, name, description).
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 when you have a UUID and need full attribute type details, but it does not explicitly state when to choose this over alternatives like mmar_list_attribute_types or mmar_get_attribute. 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 burden of behavioral disclosure. It clarifies that bendpoints are 'intermediate waypoints on a connection line,' which adds domain context, but it does not mention session requirements, return format, or error behavior. For a read operation, 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 description is two concise sentences. The first sentence immediately states the action and resource, and the second provides a useful definition of bendpoints. 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 getter tool with one parameter and no output schema, the description is largely complete. It specifies the input (relationclass instance UUID) and the result (bendpoint instances). It does not detail edge cases or return structure, but the simplicity of the tool reduces the need.
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 one parameter (relationclass_instance_uuid) with a description, giving 100% coverage. The tool description adds no further syntax or format details beyond the schema, so 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 ('Get all bendpoint instances') and targets a specific resource ('for a specific relationclass instance (connection)'). This distinguishes it from sibling tools like get_relationclass_instance or create_bendpoint by specifying exactly what is retrieved.
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: when you need bendpoints for a relationclass instance. However, it does not explicitly mention when not to use it or provide alternatives, such as get_relationclass_instance for connection details or create/update/delete bendpoint tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It only states the core operation and scope, but omits the return format, potential empty results, error conditions, or any session/auth requirements. This leaves a significant transparency gap.
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 directly states the purpose with no redundant words. Every part earns its place, and the parenthetical clarifications aid comprehension without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description sufficiently covers purpose and scope. However, it does not explicitly mention the shape of the return value (e.g., an array of class instances), which would be useful given the absence of an output schema. Still, the operation is straightforward and the siblings provide 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?
The input schema fully describes the sole parameter 'scene_instance_uuid' with type and format. The description adds the clarifying synonym 'diagram' for scene instance, which is helpful, but does not add substantial semantics beyond what the schema already provides. With 100% schema coverage, a 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 (Get), the resource (all class instances), and the scope (within a specific scene instance). It distinguishes itself from the singular variant mmar_get_class_instance and from relationclass instances, making the 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 implies the use case of retrieving all class instances in a diagram and provides the key scoping parameter. While it does not explicitly exclude alternatives like mmar_get_class_instance or mmar_get_relationclass_instances, the plural 'all' and the scene-instance scoping make the 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?
No annotations are provided, so the description carries the full burden. It does disclose that this is a read operation ('Get') and enumerates returned data (role_from, role_to, attributes, connection rules), but it omits session/auth prerequisites and behavior for invalid/nonexistent UUIDs. It is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the core verb and resource, and every word earns its place. It efficiently communicates purpose and return contents without filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-UUID getter with no output schema and one fully documented parameter, the description covers the essential return contents. Missing details like not-found behavior and session requirements are minor gaps for a read-only retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'uuid' already has full schema coverage with a clear description ('The UUID of the Relationclass to retrieve'). The main description adds no further parameter semantics beyond restating that lookup is by UUID, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb ('Get') and names the exact resource ('relation type (edge type)'), identified by UUID. It further distinguishes itself from sibling tools like mmar_get_relationclass_instance by clarifying it returns the relationclass definition, not an instance, and lists key returned components.
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 when a single relationclass's full definition is needed by UUID, but it never explicitly states when to use this tool versus alternatives like mmar_get_relationclasses_for_scene_type. There is no direct mention of when to choose it or when to avoid 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 provided, the description carries the full burden of behavioral disclosure. It adds useful context about the return content (class_references, port_references, cardinality) and implies a read-only operation via 'Get,' but it does not mention potential error behavior, permissions, or side effects. This is acceptable 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 description is two sentences, front-loaded with the primary action, and every word adds value. It avoids redundancy and is appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool with no output schema, the description is reasonably complete. It explains the return value structure (including class_references, port_references, cardinality) and implies the input key. It does not exhaustively list all possible fields, but 'including' suggests non-exhaustiveness, which is acceptable for this 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?
The schema already provides 100% coverage for the single parameter 'uuid' with a clear description ('The UUID of the Role to retrieve'). The description adds little beyond repeating 'by UUID,' so it does not substantially enhance parameter understanding 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's purpose with a specific verb and resource: 'Get the full details of a specific role by UUID.' It also differentiates from sibling tools by mentioning 'role definition' and the specific fields returned, distinguishing it from role-instance tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when needing details of a specific role by UUID) but does not explicitly state exclusions or alternatives. While it mentions role definition details, it does not directly say 'use this for role definitions, not role instances,' leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Get', which implies a read operation, but does not disclose any side effects, permissions, error behavior, or return format. This is a significant gap for a tool with no annotation support.
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 conveys the essential purpose without redundancy. It is appropriately concise for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description is sufficiently complete to convey the core function. However, it lacks guidance on return values or error scenarios, but this is somewhat mitigated by the straightforward nature of a getter.
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 parameters with a clear description ('The UUID of the RelationclassInstance'). The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('source (from) role instance'), and the scope ('specific relationclass instance'). It distinguishes this tool from the sibling mmar_get_role_to_for_relationclass_instance by explicitly specifying 'from' versus 'to'.
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 to use the tool: when retrieving the source role instance from a relationclass instance. It does not explicitly mention alternatives or exclusions, but the use case is unambiguous and the sibling tool names imply the distinction.
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 disclose behavioral traits. It does state the return content (class instance reference and cardinality), implying a read-only operation via 'Get'. However, it does not mention error behavior (e.g., invalid UUID), required authentication, or any potential side effects. The transparency 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 description is two sentences, front-loaded with the purpose and returns. Every sentence adds value and there is no redundant fluff. It is compact and easily scannable.
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 getter with one parameter and no output schema, the description is adequately complete. It names the input (UUID) and describes the key return fields. It lacks error-handling details or relationship to a session, but these are not strictly necessary for a basic retrieval tool. The richness of siblings suggests this is one of many similar getters, and the description gives enough to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the 'uuid' parameter is described as 'The UUID of the RoleInstance to retrieve'. The description merely repeats 'by its UUID' without adding new semantic details such as format expectations, default behavior, or examples. Since the schema carries the full weight, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'role instance' and identifies the lookup key ('by its UUID'). It also notes what is returned ('class instance reference and cardinality'), which distinguishes it from sibling tools like mmar_get_role (definition) and mmar_update_role_instance (mutation).
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 usage is implied: it retrieves details for a given role instance. However, the description does not explicitly state when to choose this over alternatives (e.g., mmar_get_role) nor does it mention any preconditions like having a valid session or UUID. No exclusions or forked guidance 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?
With no annotations, the description carries the full burden. It discloses that it returns an array of SceneInstance objects with UUIDs, names, and content, which is useful. However, it does not mention whether a session is required, potential error behaviors, or if the list could be empty, leaving some behavioral context implicit.
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, front-loaded with the purpose and followed by the return format. There is no redundant or extraneous information, making it efficient and well-structured.
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 list operation with one parameter and no output schema, the description provides adequate context: it states that all instances are listed and describes the return fields. It could mention authentication requirements or the possibility of large result sets, but overall it is sufficient for an agent to understand the tool's role and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter, including a description of the scene_type_uuid. The tool description adds no further parameter context, so the baseline of 3 is appropriate given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (model instances/diagrams), and the scope (for a specific SceneType). It distinguishes this from sibling tools like mmar_list_scene_types (which lists the types themselves) and mmar_get_scene_instance (which retrieves a single instance).
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 that a scene_type_uuid is needed to list all instances for that type, suggesting a workflow of first listing scene types. However, it does not explicitly state when to use this tool versus mmar_get_scene_instance or other alternatives, nor does it mention any exclusions or prerequisites like authentication.
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 only states 'Update an existing role instance' without disclosing prerequisites (e.g., session), side effects, error behavior, or whether changes are reversible. This matches the level of transparency seen in similar under-disclosed mutation tools.
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 redundant words. The first sentence states the action and the second clarifies the exact use case, making it efficient and well-structured.
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 (2 params, no output schema) and 100% schema coverage, the description adequately covers purpose and usage context. It lacks only notes on side effects or authentication, which would be nice but are not critical for such a targeted update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both parameters. The tool description adds a slight semantic hint by linking role_instance_data to the class instance reference, but it does not materially improve on the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' and names the resource 'role instance', then elaborates that it changes which class instance a connection endpoint references. This clearly distinguishes it from sibling tools like mmar_update_role and mmar_get_role_instance.
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 phrase 'Use this to change which class instance a connection endpoint references' gives clear context for when to use the tool. It does not explicitly state exclusions or alternatives, but the purpose is specific enough to guide selection among similar update tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the bare name by disclosing permanent deletion and cascading removal of attributes, ports, and role references. However, it omits what happens to class instances if any, and does not mention permission requirements or return behavior. With no annotations, the description carries the burden but still has gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and target. The first sentence states the core purpose; the second adds essential side-effect details. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with a single parameter, the description covers the action, permanence, and major cascading effects on attributes, ports, and role references. However, it does not address what happens to class instances or guard conditions (e.g., whether deletion is blocked if instances exist). The lack of an output schema is typical for delete operations, but the missing instance impact is a notable 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 coverage is 100% with a clear description for the uuid parameter, so the baseline is 3. The description adds semantic clarity by specifying that the target is a class (node type) within a metamodel, which helps disambiguate from other UUID-based entities like relation classes or instances. This enhances the schema's 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 uses a specific verb (Delete) and resource (class/node type) and clearly scopes it to a metamodel, distinguishing it from sibling delete operations like delete_relationclass and delete_class_instance. The addition of 'permanently' and the cascade effects provide a clear, non-tautological purpose.
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 permanent deletion of a metamodel class, but does not explicitly state when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or alternatives, though the 'metamodel' and 'permanently' hints give some context. This is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 accurately indicates a read operation ('Get') and specifies the return content. It does not discuss error behavior or side effects, but for a simple getter this is 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 a single sentence, front-loaded with the purpose and return details. Every word contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no output schema, the description adequately explains what it does and what it returns. It could mention error handling or explicitly note it has no side effects, but the tool is simple enough that this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the uuid parameter with 100% coverage, so the description adds no additional parameter-level meaning. The baseline is 3 as 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 it retrieves a specific meta-attribute by UUID and lists the returned fields (type, default value, sequence, UI component). This distinguishes it from instance-level getters like mmar_get_attribute_instance and type getters like mmar_get_attribute_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you have a UUID and need the full attribute definition, but it does not explicitly state when to use this over sibling alternatives or mention any exclusions. No alternative tools are referenced.
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 explicitly states the returned data (attribute value, type reference, owning element), which goes beyond the bare schema. It does not mention error/not-found behavior, but the read-only 'get' nature 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the action and key output. It is efficient and well-structured with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-UUID tool with one parameter and no output schema, the description adequately explains what is returned. It could mention the not-found behavior or response format, but the information provided is sufficient for basic usage.
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 the single uuid parameter, so the baseline is 3. The description adds no additional parameter meaning beyond what the schema already provides, only restating that the UUID identifies the instance.
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 full details of a specific attribute instance by UUID, naming the resource and the retrieval operation. It also distinguishes it from related list/get tools by emphasizing the UUID-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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for direct UUID-based retrieval but does not explicitly mention when to prefer this over listing tools like mmar_get_attribute_instances_for_class_instance. No alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It indicates a read operation via 'Get' and implies a list of instances as the return, but it does not explicitly state read-only behavior, authentication requirements, or any side effects. 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 description is a single, front-loaded sentence with no wasted words. It includes a helpful parenthetical clarification and is appropriately sized for the tool's simplicity.
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-by-parent tool with one parameter and no output schema, the description and schema are sufficient. It clarifies the key concept (class instance = element) but does not elaborate on return format or relationships to other tools, which is acceptable for this complexity level.
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 the single parameter 'class_instance_uuid' described as 'The UUID of the ClassInstance'. The description adds no additional meaning beyond the schema, so 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 ('Get'), the resource ('all attribute instances'), and the scope ('for a specific class instance'). This distinguishes it from sibling tools like mmar_get_attribute_instance (singular) and mmar_get_attribute_instances_for_relationclass_instance (different target).
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 the tool is used to retrieve attribute instances associated with a class instance, with the parenthetical '(element)' clarifying the context. It does not explicitly mention exclusions or alternatives, but the sibling tool names make the different scopes evident, so the 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 provided, so the description carries the full burden. It discloses that the tool returns the class with its attributes, ports, and geometry, indicating a read operation. However, it does not mention prerequisites (e.g., active session from mmar_login), error behavior for missing UUIDs, or any side effects. This is partially transparent but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences that immediately state the action, target, and return content. No redundant or vague wording; it is well-structured and 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 one-parameter getter with no output schema, the description is mostly complete: it states what the tool does and what it returns (attributes, ports, geometry). It could mention expected prerequisites or error handling, but given the simplicity, it covers the essential context. A score of 4 reflects this slight gap.
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 one parameter (uuid) with a clear description, and schema description coverage is 100%. The tool description adds minimal meaning beyond the schema, mainly clarifying that the UUID refers to a class (node type). Thus, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('specific class (node type) by its UUID'). It also specifies the returned content ('attributes, ports, and geometry (VizRep)'), and the name/scope distinguishes it from sibling getters like mmar_get_relationclass or mmar_get_attribute_type.
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 when you have a class UUID and need full details. It does not explicitly mention alternatives or exclusions, but the context is sufficient to understand when to use this tool versus listing classes for a scene type.
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 burden of behavioral disclosure. It clearly indicates a read-only getter operation, but does not disclose effects like errors, sorting, or whether abstract classes are included. The contextual explanation of 'SceneType' and 'classes' adds some clarity, but key behavioral details remain unstated.
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 efficiently captures the purpose and adds relevant context. Every word contributes value; there is zero redundancy or 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 tool's low complexity (1 parameter) and lack of output schema, the description is largely adequate. It explains the return concept ('all classes') and the input context ('specific SceneType'). However, it does not describe the return format (e.g., array of class objects) or mention potential pitfalls, which leaves a small gap.
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 parameter (scene_type_uuid) with a description, so the baseline is 3. The tool description adds context by explaining that a SceneType is a modeling language, but does not provide additional parameter-specific meaning beyond what the schema already offers.
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 ('Get'), the resource ('all classes... node/shape types'), and the scope ('defined in a specific modeling language (SceneType)'). It also adds explanatory context about what classes are, distinguishing it from siblings like mmar_get_class (singular) and mmar_get_relationclasses_for_scene_type.
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 its usage by specifying it retrieves all classes for a given SceneType, which distinguishes it from mmar_get_class (single class). However, it does not explicitly state when to use this tool over alternatives or note any exclusions, so it stops short of full 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 provided, so the description must carry the transparency burden. It indicates a read operation ('Get all') and adds helpful context that these are connections/edges. However, it does not disclose any potential side effects, authentication requirements, or error behavior. For a simple getter, 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?
A single, focused sentence that leads with the action and resource. No redundant words or restatement of the tool name. It front-loads the core purpose and clarifies domain jargon in parentheses.
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 list-retrieval tool with no output schema, the description is complete enough: it names the input (scene instance) and the output (all relationclass instances). It could add details like return format or session requirements, but the explicit scope makes it sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter (scene_instance_uuid) with 100% coverage, so the description does not need to add parameter details. The description's mention of 'specific scene instance' aligns with the schema, but adds no extra meaning 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 identifies the action (get all relationclass instances) and the resource scope (within a specific scene instance), clarifying that these represent connections/edges in a diagram. This distinguishes it from the singular mmar_get_relationclass_instance and other retrieval 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?
The description implies when to use this tool: when you need all relationclass instances in a given scene instance. It does not explicitly contrast with alternatives like mmar_get_relationclass_instance, but the plural 'instances' and scene scoping provide enough contextual guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read operation ('Get') but does not elaborate on return details, error handling, authentication requirements, or any side effects. For a simple getter, the basic action is clear, but additional context is lacking.
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 is immediately understandable. It contains no fluff or redundancy and earns its place by clearly identifying the exact resource and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description adequately explains what is retrieved (the destination role instance). It could mention behavior when the relationclass instance or role instance does not exist, but for a basic getter, the information provided is sufficient. The sibling distinction via 'to' helps contextualize its place among related 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 schema description covers 100% of the parameter's meaning ('The UUID of the RelationclassInstance'). The description adds no extra semantic value beyond restating 'a specific relationclass instance', so a 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 ('Get') and the specific resource ('the destination (to) role instance of a specific relationclass instance'). It explicitly distinguishes from the sibling tool by including '(to)' versus the corresponding 'from' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need the destination role instance of a relationclass instance. While it doesn't explicitly name the sibling tool or state exclusions, the 'to' qualifier provides clear context for selecting this over the 'from' variant. No additional alternatives or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of conveying behavior. The use of 'Get' and 'Returns' implies a read-only operation, and enumerating the returned components adds useful detail. However, it does not explicitly state safety, error handling, or potential for large payloads, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every phrase adds value (e.g., listing the included components). It is concise and well-structured with no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description adequately explains what is returned and the principal use case. It lacks explicit mention of error conditions or response format, but given the low complexity, it is sufficiently 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 fully documents the single 'uuid' parameter with a clear description, so schema coverage is 100%. The description adds little beyond this, merely restating that the UUID identifies the SceneType. Thus it meets the baseline for well-documented parameters 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 states a specific verb ('Get') and resource ('a specific modeling language (SceneType)'), and clarifies the scope by listing all included components (classes, relationclasses, attributes, ports, roles). This distinguishes it from sibling getters for individual components such as mmar_get_classes_for_scene_type.
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 indicates this tool is for retrieving the complete SceneType, which implies using it when full details are needed. However, it does not explicitly state when not to use it or mention alternatives, though the sibling list and the mention of 'full details' provide implicit 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?
No annotations are provided, so the description carries the full burden. It discloses a critical non-obvious behavior: 'The API does NOT auto-create attribute instances. You MUST include them in the payload.' This prevents a common failure. It does not mention response format or error cases, but the warning is highly valuable.
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 purpose, then a bolded IMPORTANT warning, and finally an example. The example is lengthy but directly useful for constructing the payload. No wasted sentences; the structure is logical and readable.
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 (nested attribute instances) and lack of an output schema, the description thoroughly explains the input requirements. It does not cover return values or error handling, but for a creation tool with no output schema, the input focus is appropriate. The warning about attribute instances makes it complete enough to use 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 schema already provides descriptions for both parameters, so coverage is 100%. The description adds further semantic value by explaining the required structure of the JSON string and giving a concrete payload example, especially the attribute_instance array with uuid, name, value, and uuid_attribute. This goes beyond the schema's brief property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Create a new class instance (element/node) within a scene instance,' providing a specific verb and resource with clear scope. This distinguishes it from sibling tools like mmar_create_scene_instance or mmar_create_attribute_for_class.
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 does not explicitly state when to use this tool vs. alternatives, but the purpose and the important note about attribute instances imply when it is needed. It would benefit from saying 'Use this to add an element to an existing scene instance' and possibly contrasting with update or delete operations.
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 burden. It discloses what the tool returns (the complete SceneInstance with nested parts), but it does not explicitly state read-only nature, session/auth requirements, or error behavior. Since it's a read operation, the risk is lower, but the disclosure is limited to 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 two sentences, front-loaded with the primary action ('Get the full details...') and followed by a concise list of return contents. No redundant or filler language.
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 simple one-parameter getter with no output schema, the description adequately explains both the purpose and the return structure. It specifies the type of instance and the included sub-instances, making it complete for the tool's scope.
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 provides 100% coverage for the uuid parameter with a description. The tool description adds no additional meaning beyond 'by its UUID,' which is already implied. Baseline of 3 is appropriate since 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 tool's function: 'Get the full details of a specific model instance (diagram) by its UUID.' It uses a specific verb and resource, and the second sentence enumerates the returned components (class instances, relationclass instances, etc.), which distinguishes it from sibling getters and listers.
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 the usage scenario: when you need full details of a specific scene instance by its UUID. It gives clear context (specific instance, full details) but does not explicitly state when not to use it or name alternatives such as mmar_list_scene_instances. This fits 'clear context, no exclusions.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral trait: the tool expects a complete desired state, meaning it replaces the entire instance rather than patching fields. It also hints at supported fields (position, attribute instances). However, it does not disclose side effects, reversibility, permission requirements, or what happens to omitted fields, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, then provides a concise instruction about the required payload. No unnecessary words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the critical 'full-state' requirement, but lacks details on expected response, error conditions, or the exact structure of the JSON data. Without annotations or an output schema, the agent must infer several behavioral aspects. The trailing 'etc.' adds ambiguity about field completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with 100% coverage. The description adds meaning to class_instance_data by specifying it must represent the complete desired state including position and attribute instances, which is more specific than the schema's 'updated ClassInstance data'.
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 ('Update') and resource ('existing class instance'), and distinguishes from sibling tools by emphasizing 'complete desired state' which is unique to update operations. The mention of 'position, attribute instances, etc.' clarifies the scope of the update.
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 the tool is for modifying an existing class instance and explicitly requires sending the complete desired state, signaling this is a full replacement rather than a partial update. However, it does not mention when to use this over alternatives like update_relationclass_instance or provide 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 burden of disclosing behavior. It does reveal the key behavioral trait that a complete desired state must be sent (indicating a PUT-like overwrite), but it does not mention prerequisites, error handling, or the nature of the response. This is informative 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 description is two short sentences, front-loaded with the main action, and every word contributes. There is no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description is adequate but not fully complete. It explains the core behavior but omits error conditions or any note about the requirement that the port must exist. Given its simplicity, it is minimally viable but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for both parameters. The description adds meaningful value by clarifying that port_data must contain the complete desired state, not just changes, which is a semantic nuance not explicit 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 'Update an existing port' with a specific verb and resource, distinguishing it from create/get operations. The added instruction 'Send the complete desired state of the port' further differentiates it from partial update tools, making its 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 that this tool is for updating an existing port, and the phrase 'Send the complete desired state' gives explicit guidance on how to use it (full replacement rather than partial patch). It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select it 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 burden of disclosing side effects. It introduces the 'complete desired state' requirement, which hints at an overwrite-style update, but it does not explicitly state that existing data will be replaced or mention permission/session prerequisites, error behavior, or reversibility. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action and resource, and each sentence earns its place. The first defines the purpose; the second clarifies the update semantics. There is no redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the essential purpose and update mode but lacks warnings about overwrite semantics, authentication requirements, or expected return values. Given the tool's simplicity and full schema coverage, it is adequate but not complete — an agent might not know that sending incomplete data could result in loss of existing fields. No output schema or annotations further reduce the context available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with full coverage (100%), so the baseline is 3. The description adds value by specifying that 'relationclass_instance_data' must be the complete desired state, not a partial patch. This extra semantic clarity elevates the score above the schema-only 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 action ('Update an existing relationclass instance') and identifies the resource type, adding the parenthetical '(connection/edge)' to distinguish it from class instances. It also specifies the update mode ('Send the complete desired state'), making the tool's purpose unambiguous and distinct from sibling update 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?
The description provides clear context: it is for updating an existing relationclass instance. The phrase 'Send the complete desired state' implies a full-state replacement, guiding the user on how to construct the request. However, it does not explicitly mention when not to use this tool or point to alternatives (e.g., for partial updates or deleting), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It adds a key constraint (class_references must exist) and enumerates the JSON structure, but does not mention side effects, return value, or authentication requirements, so transparency 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 description is compact with three focused sentences: the core action, an important prerequisite, and the data structure. It is front-loaded 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 absence of an output schema and annotations, the description covers the essential inputs and a critical prerequisite, but it does not specify error behavior or what the response contains. It is sufficient for routine invocation, though not exhaustive.
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 already describes both parameters, but the description goes further by detailing the exact shape of relationclass_data including role_from/role_to with class_references and bendpoint, which adds meaningful guidance beyond the schema's high-level summary.
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 ('Create'), the resource ('relationclass'), and the context ('add it to an existing SceneType'). It also distinguishes from sibling tools like mmar_create_relationclass_instance by specifying it creates the relation type, not an instance.
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 critical prerequisite that referenced classes must already exist in the SceneType. This gives practical guidance on when it is appropriate to call this tool, though it doesn't explicitly contrast with sibling tools like mmar_update_relationclass.
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 does add valuable behavioral instructions, such as generating a new UUID v4 and enumerating optional arrays within scene_instance_data. However, it does not disclose side effects like session requirements, validation behavior, or what the tool returns, leaving some uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the tool's purpose, and the second explains the required data structure. It is front-loaded, concise, and contains no irrelevant information.
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 absence of an output schema and annotations, the description covers the core purpose and input requirements effectively. It lacks an explicit mention of return values or potential errors, but the essential information for invoking the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with 100% description coverage. The description goes beyond this by explicitly listing the optional arrays (class_instances, relationclasses_instances, role_instances, attribute_instances, port_instances) and instructing the agent to generate a new UUID v4, adding meaningful semantic detail.
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+resource phrase: 'Create a new model instance (diagram) for a specific SceneType.' It clearly differentiates this from creating a SceneType or other instance types by specifying 'model instance' and 'for a specific SceneType.'
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: it is for creating a new scene instance for a given SceneType, which implies when to use it. However, it does not explicitly mention alternatives or exclusion criteria, like 'use this when creating a diagram instance rather than a scene type.'
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 irreversibility ('cannot be undone') and the cascading deletion of all associated contents, which are the critical behavioral traits for a destructive operation. It does not mention prerequisites like session validity, but that is a general concern across all tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action verb 'Delete', and contains no filler. It efficiently communicates the scope and irreversibility of the operation.
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 sufficiently covers the tool's purpose and key behavioral implications for a simple one-parameter destructive operation. It does not need to detail return values since no output schema exists, and the cascade behavior is explicitly stated.
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 fully describes the uuid parameter with a clear description, so the description adds no additional semantic value. According to the baseline rule for high schema coverage, a 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 deletes a SceneType and its entire contents, using the explicit verb 'Delete' and specifying the resource scope. It distinguishes itself from sibling delete tools by noting the cascading deletion of all associated contents, which is unique to scene type deletion.
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 the primary use case: when you want to permanently remove an entire modeling language. It does not explicitly name alternative tools for more targeted deletion, but the context makes it clear that this is the full-scope deletion option.
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?
No annotations are present, so the description carries the full burden. It conveys a read-only operation via 'Get'/'Returns' and discloses what is returned (attribute instances, port instances, position). It could mention session requirements or error behavior, but for a simple getter 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 description is a single, front-loaded sentence with no fluff. It states the action, the target, the identifier, and the return contents, making every word useful.
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 single-parameter getter with no output schema, this description supplies the key selection information and a high-level return structure. It doesn't mention prerequisites like an active session or error responses, but those are not critical for this basic read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the uuid parameter already has a clear description. The description only restates 'by its UUID' and adds no additional format, constraints, or usage nuance, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Get... class instance') and identifies the entry point by UUID. It also clarifies the target as an 'element/node' and enumerates the returned content, distinguishing it from siblings like mmar_get_class_instances (plural listing) and mmar_get_relationclass_instance.
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 context is clear: use this tool when you need detailed data for one specific class instance identified by UUID. It doesn't explicitly name alternatives or exclusion criteria, but the singular 'specific' and the contrast with sibling list tools imply the intended usage.
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 conveys a read-only list operation and hints that output includes UUIDs, but does not disclose authentication requirements, return format, or any potential side effects. However, for a simple list-all tool, this is reasonably 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?
Two sentences, front-loaded with the main purpose, followed by a practical usage note. Every word earns its place with no fluff, making it highly concise and well-structured.
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 low complexity (no parameters, no output schema), the description covers the essential purpose and prerequisite. It could explicitly state return structure, but the mention of UUIDs provides a clear expectation. Slightly more detail about session requirements would make it complete, but it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific semantics since none exist, but it does clarify the content of the list (attribute types and their UUIDs), which 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?
The description uses a specific verb ('List') and resource ('all available attribute types in MM-AR') with concrete examples (String, Float, Integer, Boolean, Enumeration, Table). It clearly distinguishes from siblings like mmar_get_attribute_type which likely retrieves a single type, making the 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?
It explicitly states when this tool is needed ('You MUST know these UUIDs before creating attributes on classes or relationclasses'), providing clear usage context. It does not explicitly mention alternatives like mmar_get_attribute_type, but the context strongly implies this is the 'list all' counterpart.
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 discloses that the server diffs the desired state against the current state and applies changes to attributes, ports, and other properties, which is important behavioral context beyond just 'update'. However, it doesn't mention auth requirements or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with the key action front-loaded. It communicates purpose and behavior with no waste.
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 only 2 simple params and no output schema, the description adequately covers the tool's purpose and key behavior. It could mention response format or require existing class, but the 'existing class' phrase implies it, keeping completeness sufficient for low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage, describing uuid and class_data (with 'complete desired state'). The description adds the diff/apply behavior but doesn't provide additional parameter-level semantics beyond what the schema states.
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 an existing class (node type), using a specific verb and resource. It distinguishes itself from sibling tools like update_class_instance by specifying 'class (node type)'.
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 on when to use the tool: when updating an existing class, and instructs to send the complete desired state. It doesn't explicitly exclude other tools, but the 'node type' clarification helps differentiate from instance-level updates.
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 key behavioral trait that the update requires the complete desired state, implying a replace-like semantics. But it does not mention permissions, side effects, or return format, which are important 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 two short sentences, front-loaded with the primary purpose and immediately followed by the critical usage hint. 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 update tool with well-specified parameters and no output schema, the description is largely complete. It conveys the essential requirement of sending the full state, which is likely sufficient for an agent to invoke it correctly. It could mention return behavior, but this is not a major gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds semantic value by clarifying that 'port_instance_data' should be the complete desired state, which goes beyond the schema's 'updated PortInstance data' wording.
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 verb ('Update') and resource ('existing port instance'), distinguishing it from sibling tools like mmar_update_port (which updates a port definition) and mmar_create_port_instance (which creates new instances).
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 provides a clear usage guideline: 'Send the complete desired state' informs the agent that this update requires full replacement rather than partial modification. However, it does not explicitly mention when to use this tool over alternatives or provide 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?
No annotations are provided, so the description carries the full burden. It usefully discloses the diff-and-apply behavior and the need for the complete desired state, but it omits authentication requirements, potential side effects, or response details. 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 description is a single sentence, front-loaded with the verb and object, and packs critical usage details (complete state, diff behavior) without any filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema or annotations, the description is largely sufficient: it identifies the target, the expected payload shape, and the update semantics. Slight vagueness around 'other properties' and no mention of return behavior prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters well (100% coverage). The description adds important meaning by clarifying that relationclass_data must be the complete desired state and that the server diffs it against the current state, which prevents the agent from treating it as a partial patch.
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 ('Update') on a specific resource ('relationclass') and clarifies it's an edge type. This distinguishes it from sibling tools like create_relationclass, delete_relationclass, and get_relationclass.
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: use this tool to update an existing relationclass and send the complete desired state, implying it is not for creation or deletion. However, it doesn't explicitly name alternatives or state when not to use it relative to similar update tools like update_class.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal an important trait: 'Send the complete desired state of the role', implying a full update semantics. Yet it lacks clarity on side effects, error cases, or permissions, leaving significant behavioral transparency 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?
Two sentences, front-loaded with the action and resource, followed by usage scenarios and a key behavioral instruction. Every sentence is purposeful and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with no output schema and only two parameters, the description adequately covers purpose, usage context, and a critical behavioral constraint. It does not discuss prerequisites like existing role existence or error handling, but these are not strictly necessary given the tool's straightforward nature.
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 100%, so the baseline is 3. The description adds value beyond the schema by explicitly tying role_data to cardinality and class_references, and by emphasizing the 'complete desired state' requirement, which clarifies how to construct the JSON parameter.
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 ('Update') and the resource ('an existing role on a relationclass'), distinguishing it from other update tools by specifying the target. It also names the key updatable aspects (cardinality, class_references), reinforcing its purpose.
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 provides explicit usage guidance: 'Use this to change cardinality (min/max) or which classes a role can connect to', giving clear context for when to invoke this tool. However, it does not mention alternatives or when not to use it, so it misses the explicit exclusions needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the incremental add behavior (rather than recreating the whole SceneType) and details required fields in class_data. However, it does not mention return values, error handling, or prerequisites like the SceneType existing. This is a moderate level of transparency 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 appropriately sized: a two-sentence overview with a concise bullet-like list of required fields. It is front-loaded with the primary purpose and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should ideally cover what the tool returns or confirms. It doesn't. It also omits validation behavior and prerequisites. However, it does convey the core operation and required parameters, making it sufficient for basic invocation but not fully complete for an agent anticipating outcomes.
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 already describes both parameters with 100% coverage. The description adds value by specifying the exact required keys inside class_data (uuid, name, geometry, is_reusable, is_abstract, attributes, ports) and clarifies that geometry can be null and attributes/ports are arrays. This goes beyond the schema's 'including uuid, name, attributes, ports, geometry' and covers missing fields.
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 function: 'Create a new class (node/shape type) and add it to an existing SceneType.' It uses a specific verb (create) and resource (class), and distinguishes from siblings by emphasizing 'instead of recreating the whole SceneType.' This differentiates it from scene-type-level creation and update operations.
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?
Explicit guidance is provided: 'Use this for incremental metamodel building instead of recreating the whole SceneType.' This gives a clear when-to-use context and an alternative to avoid, directly helping the agent decide between this tool and others like update_scene_type or create_scene_type.
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?
No annotations are provided, so the description carries the full load. It discloses that deletion is permanent and cascades to roles, attributes, and ports—key behavioral traits for a destructive operation. It does not cover session prerequisites or error handling, but the most important consequences are clearly stated.
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 states the primary action and the most crucial consequence (permanent deletion and cascade). Every word earns its place, with no redundancy or irrelevant detail.
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 one-parameter, no-output-schema delete tool, the description is complete. It tells the agent what the tool does, what it affects, and that the operation is irreversible. Given the simple signature and the explicit cascade behavior, an agent has enough information to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter (uuid) with 100% coverage, so the description adds no extra parameter-level detail. The baseline of 3 is appropriate since the schema does the heavy lifting and the description focuses on overall behavior rather than the parameter itself.
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 ('Delete') with a clear resource ('relationclass') and clarifies it is an 'edge type' and acts on a 'metamodel'. The cascade note also distinguishes it from other delete tools by specifying the scope of what gets deleted.
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 tool's name and description make it clear this is for deleting relationclasses, and the permanence warning guides usage. However, it does not explicitly state when not to use it or mention alternatives, though the context and sibling tool list make 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the important behavioral detail that line_points are auto-populated from source/target coordinates, so the agent doesn't need to provide them. It also details the required fields in the JSON structure. Since no annotations are provided, this transparency is valuable, though additional side effects are not 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 concise and well-structured: a single-sentence purpose, a bulleted list of required components, and a clear note about auto-population. Every sentence adds value with no 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 description covers the input structure and key behavior well for a create operation. However, it does not state the return value or any post-conditions, which would be helpful given there is no output schema. Overall, it is nearly complete for invoking the 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 coverage is 100% with both parameters described, but the description goes further by explaining the nested structure of relationclass_instance_data (role_instance_from/to, attribute_instance) and the auto-population of line_points. This adds significant semantic 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 'Create a new relationclass instance (connection/edge) within a scene instance', specifying the verb (create), resource (relationclass instance), and context (within a scene instance). This distinguishes it from sibling tools like mmar_create_class_instance and mmar_create_scene_instance.
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 context through 'connection/edge' and 'within a scene instance', making it clear this is for creating relations in a scene. However, it does not explicitly state when not to use it or mention alternatives like mmar_update_relationclass_instance. The use case is implied rather than spelled out.
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 responsibility for disclosing behavior. It states that the tool 'Returns an array of SceneType objects with their UUIDs and names,' which informs the agent of the output format. It also explains the conceptual nature of SceneTypes. While it does not explicitly state that it is read-only, the wording 'List' and 'Returns' strongly implies a non-mutating operation, which is adequate for this simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is elegantly concise—two sentences that front-load the primary action and follow with a clear explanation of what is returned. No redundant information is included, and every word adds value.
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 simplicity (no parameters, no output schema, no annotations), the description is fully complete: it explains what the tool does, what the returned objects represent, and the output format. No additional context is needed 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the description is not required to explain parameter semantics. The baseline for 0 parameters is 4, which is appropriate here.
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: 'List all available modeling languages (SceneTypes) in MM-AR.' It uses a specific verb ('List') and resource ('modeling languages'), and explicitly notes it returns all available types, distinguishing it from sibling tools like mmar_get_scene_type that retrieve a single type.
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 context for when to use this tool is clear from the phrase 'all available'—an agent should use it when needing an enumeration of scene types. However, it does not explicitly name alternatives or provide when-not-to-use conditions, so it falls short of 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. It discloses that the tool must be called first and that it returns a confirmation of an active session. While it does not detail error handling or session duration, it provides essential behavioral context for a login 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 exactly two sentences, with the purpose and the key constraint (MUST be called first) front-loaded. No redundant or irrelevant information is present, making it extremely concise and well-structured.
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 login tool with no output schema, the description adequately explains the return value ('confirmation that the session is active') and the ordering requirement. Given the low complexity of the tool, this is complete enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters have descriptive text with examples ('e.g., admin'). The description adds nothing beyond the schema, but the schema already fully documents the parameters, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Log in to the MM-AR metamodeling platform' with a specific verb and resource. It also distinguishes from siblings by explicitly stating it is the mandatory first step, setting it apart from all other tools.
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 usage guidance: 'This MUST be called first before using any other MM-AR tools.' This clearly indicates when to use the tool and the prerequisite ordering, leaving no ambiguity about its role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key behavioral detail of clearing the stored session token, which is the core side effect. It does not mention edge cases like idempotency or failure when not logged in, but for a simple logout 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 description is a single, front-loaded sentence that states the action, target, and mechanism. Every word contributes to clarity, with no unnecessary detail or repetition.
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?
The tool is trivial: no parameters, no output schema, no annotations. The description fully explains the tool's purpose and behavior, leaving no significant gaps. Additional details about return values or error handling are not necessary given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter details, but none are needed. The schema is empty, and the description clearly explains what the tool does without requiring parameter explanations.
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 'Log out from the MM-AR platform' with a specific verb and resource, and explains the mechanism 'by clearing the stored session token.' This distinguishes it from siblings like mmar_login and mmar_check_session.
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 the usage context: it is for ending a session on the platform. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous, making it clear when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 and does an excellent job: it discloses the smart diff default, the dangerous hardpatch behavior with a warning, and requires the complete desired state. This is far more transparent than typical mutation tools.
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?
Three sentences, each serving a purpose: stating the action, explaining the hardpatch option, and giving a payload instruction. It is concise, front-loaded, and free of 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?
The description adequately covers the tool's core behavior, modes, and payload requirement, referencing mmar_create_scene_type for structure. It doesn't specify return values, but with no output schema and high-quality parameter descriptions, this is a minor 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 coverage is 100%, so the baseline is 3. The description adds value by explaining the hardpatch flag's semantics and emphasizing that scene_type_data must be the complete desired state, going beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Update an existing modeling language (SceneType)', using a specific verb and resource. This distinguishes it from sibling tools like mmar_create_scene_type and mmar_delete_scene_type.
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 explains the default additive mode and the hardpatch full-replacement mode, and instructs to send the complete desired state. It implies the tool is for modifying existing SceneTypes, though it doesn't explicitly name alternatives or 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses critical behaviors: atomicity (all or nothing), duplicate UUID conflict (409), the need to pre-generate all UUIDs, and the ordering constraint that classes must be created before relationclasses. It also provides the complete expected JSON structure, which is essential for correct use.
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: a one-sentence purpose, numbered important rules, and a JSON template. Every sentence provides actionable information. Despite its length, it is appropriately sized for the tool's complexity and front-loads the most critical facts (atomic transaction, prerequisites).
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 complex tool with no output schema and no annotations, the description is remarkably complete: it covers input structure, prerequisites, ordering, error conditions, and atomicity. It does not explicitly mention the success return value or authentication requirements, but those are less critical for invoking the tool correctly and can be inferred from 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?
Although the schema describes both parameters, the description adds immense value, especially for scene_type_data, by giving the full nested JSON structure with examples for classes, relationclasses, roles, and attribute references. It clarifies UUID generation and the exact shape of the payload, far exceeding the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a complete modeling language (SceneType) in MM-AR in a SINGLE atomic transaction.' It uses a specific verb, resource, and scope, and distinguishes itself from sibling creation tools by being the 'primary way to create metamodels' as a whole, rather than incremental tools like mmar_create_class.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: this is the primary way to create metamodels, and it gives explicit prerequisites (call mmar_list_attribute_types FIRST) and ordering rules. However, it does not explicitly state when NOT to use this tool versus creating entities individually with sibling tools, though 'primary way' implies 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 full transparency burden. It discloses the smart diffing behavior (new elements added, existing updated) and that new relationclass instances will be created. However, it does not mention potential side effects like deletion of omitted elements or failure modes, leaving a minor gap.
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 with the primary purpose, followed by an important usage note and payload requirements. Every sentence adds value; no fluff or 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 description covers the core purpose, recommended use cases, required payload structure, and key behavioral traits. It lacks explicit mention of return values or error handling, but for an update tool with no output schema, this is a minor omission. Overall it is suitably complete for an agent to 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?
Although schema descriptions already cover the two parameters at 100%, the description enriches them by specifying the minimum required fields inside the JSON payload (uuid, name, uuid_scene_type) and detailing the relationclasses_instances array structure. This goes well beyond the schema text.
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 and resource: 'Update an existing model instance (diagram).' It further clarifies the smart diffing behavior, distinguishing this tool from simple create/delete operations and from the many sibling tools.
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 explicitly states this is the RECOMMENDED way to add connections (relationclass instances), providing a clear use case. It also specifies required payload fields (uuid_scene_type, uuid, name) and the structure for relationclasses_instances, offering actionable guidance.
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:

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

Score Badge

Copy to your README.md:

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

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/ProTech001/mmar-mcp-server'

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