robot-tool-mcp
Server Quality Checklist
Latest release: v1.2.2
- Disambiguation5/5
Each tool corresponds to a distinct ROBOT command with a clearly defined function. Despite some similarities (e.g., filter/remove, report/verify), descriptions provide enough detail to differentiate them. No two tools have overlapping primary purposes.
Naming Consistency5/5All tools follow a consistent 'robot_<verb>' pattern in lowercase snake_case. The naming is predictable and uniform throughout the entire set.
Tool Count4/5With 26 tools, the server covers a comprehensive set of ontology operations. While on the higher side, each tool serves a necessary function for the domain, and the count is justified by the complexity of ontology management.
Completeness4/5The tool surface covers most major ROBOT commands including creation, conversion, reasoning, querying, and validation. Minor gaps exist (e.g., no explicit 'create' tool, but template covers it), but overall the set enables full ontology lifecycle management.
Average 3.5/5 across 26 of 26 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under BSD 2-Clause "Simplified" License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It reveals the tool exports data and explains three parameters, but it does not mention side effects, required permissions, return value structure, or the behavior of the other 15 parameters. The lack of coverage 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (three sentences) and front-loaded with the purpose. It uses clear examples for parameters. Every sentence contributes, though listing all formats in the first sentence slightly clutters the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (18) and lack of schema descriptions or annotations, the description is insufficient. It covers only three parameters and omits critical details like the input source, export path, format validation, and other options. The presence of an output schema does not compensate for missing parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, placing the burden on the description. The description explains three key parameters (header, include, sort) with examples, adding value beyond the schema. However, it ignores the majority of the 18 parameters, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports ontology data to table formats (CSV, TSV, JSON, HTML, XLSX), which is specific and distinguishes it from other robot tools like robot_query or robot_convert. However, it does not explicitly differentiate from all siblings, so it loses a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives usage hints for a few parameters (header, include, sort) but does not provide guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. This is insufficient for a tool with many siblings.
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 fully disclose behavior. It mentions removal and promotion but omits important details: whether the operation is destructive or reversible, what happens to class relationships, and the impact on files. Given 14 parameters, the description is insufficiently 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the main action. Every sentence adds value: the first defines the purpose, the second explains the core logic and key parameters. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 14 parameters and an output schema (context signal), the description only covers the core algorithm. It does not explain input/output formats, the meaning of common params like verbose or strict, or the structure of the output. This leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds meaning for only 3 of 14 parameters (threshold, precious, precious_terms). The remaining parameters (input, output, working_directory, etc.) are left entirely to the schema, which provides no descriptions. This is barely adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Collapse class hierarchies') and the resource ('class hierarchies'), with specific behavior regarding intermediate classes and subclasses. However, it does not explicitly distinguish this tool from siblings like robot_reduce or robot_repair, which might also manipulate hierarchies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on using parameters like threshold and precious/precious_terms to control behavior. However, it lacks context on when to choose this tool over alternatives (e.g., vs robot_merge) or when not to use it (e.g., if no intermediate classes exist).
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 behavioral disclosure burden. It mentions three mapping modes but does not disclose side effects (e.g., in-place modification), required output, permissions, or failure modes. Parameters like allow_missing_entities and allow_duplicates are not explained, leaving behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of moderate length. It front-loads the purpose and then lists mapping options. However, it could be more concise or better structured (e.g., bullet points for mapping methods). Every sentence is relevant, but some information is repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 16 parameters and many undocumented, the description is incomplete. The output schema exists but its contents are not described; return values and error conditions are omitted. Important parameters like allow_missing_entities and allow_duplicates lack explanation. The description covers only the core renaming modes, missing much context needed for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains mapping, mappings, and prefix_mappings, but neglects 13 other parameters including input, output, allow_missing_entities, and working_directory. The description adds meaning for only a fraction of the parameters, leaving most undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Rename entity IRIs via full replacement or prefix-based renaming' with verb and resource. It lists three mapping methods (mapping, mappings, prefix_mappings), distinguishing it from sibling tools like robot_annotate. However, it does not specify the type of entities (e.g., ontology entities) or the input format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit usage for each mapping parameter: 'Use mapping for individual IRI replacements... Use mappings to point to a TSV file... Use prefix_mappings for bulk prefix replacement.' This helps the agent choose the right parameter. It does not explicitly state when not to use the tool or compare to alternatives, but the guidance is clear for the tool's own parameters.
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 full behavioral disclosure. It does not mention side effects, error behavior, how missing terms are handled, or whether the tool modifies the original ontology. The description only covers the extraction methods and seed term specification, lacking transparency on key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose in the first sentence. The list of methods is well-structured with brief explanations. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 23 parameters and no annotations, the description is incomplete. It omits explanations for many parameters and does not describe the output despite an output schema existing. The description covers only the core extraction logic and methods, leaving the agent without sufficient context for full usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to explain many parameters. It only explains 'term', 'term_file', and hints at 'upper_term'/'lower_term' for MIREOT. The remaining 21 parameters (e.g., imports, individuals, intermediates) are not described, leaving the agent with minimal semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'Extract a subset module from a larger ontology.' It lists specific methods (STAR, BOT, TOP, MIREOT, subset) with brief explanations, clearly distinguishing itself from sibling tools like robot_filter or robot_remove, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use robot_extract versus sibling tools like robot_filter or robot_remove. It does not explain the context for using different extraction methods relative to alternatives, leaving the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It states that the tool expands macros into axioms, but omits prerequisites, side effects (e.g., whether original annotations are preserved), permissions needed, or any destructive potential. The description is minimal, leaving significant behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, with the main purpose in the first sentence. However, it could benefit from a more structured layout (e.g., bullet points for parameters) to improve scannability. The lack of whitespace reduces readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, 0% schema coverage) and 25 siblings, the description is insufficient. It only covers the macro expansion aspect and a few parameters. The output schema exists, but the agent lacks guidance on input/output file handling, prefixes, and other controls, making it hard to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must explain all 14 parameters. It only details three (expand_term, no_expand_term, annotate_expansion_axioms). Common parameters like input, output, prefixes, etc., are left undefined, forcing the agent to rely on naming conventions or external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core purpose: 'Expand shortcut annotation properties (macros) into OWL axioms.' It uses a specific verb ('Expand') and resource ('annotation properties'), distinguishing it from sibling tools like robot_annotate (which adds annotations) or robot_collapse (which reduces).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on three key parameters (expand_term, no_expand_term, annotate_expansion_axioms), but lacks any context on when to use this tool versus the 25 sibling tools. No explicit 'when not to use' or alternative names are mentioned, so the agent has to infer the appropriate usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions types of repairs but fails to state whether the tool modifies the ontology in place, requires write permissions, or has side effects. The agent is left guessing about destructive potential and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no redundant text. However, it could be better structured with bullet points or explicit mapping to parameters without increasing length significantly. It front-loads the general purpose but lacks detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, no schema descriptions, no annotations) and presence of an output schema, the description is too sparse. It fails to provide sufficient context for an agent to correctly invoke the tool, especially regarding parameter usage and output interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain parameters. It only references 'invalid_references' and 'merge_axiom_annotations' indirectly via the listed repairs, leaving 12 other parameters (e.g., input, output, catalog, prefixes) completely unexplained. The description adds minimal value beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool fixes common ontology problems and lists three specific types of repairs: updating deprecated class references, merging duplicate axiom annotations, and fixing invalid references. It effectively distinguishes itself from sibling tools which perform other operations like annotation, conversion, or filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ontology repair tasks but does not explicitly state when to use this tool over alternatives like robot_validate_profile or robot_verify. No context on prerequisites or exclusions is provided, leaving the agent with only implied 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?
The description lacks details on side effects, such as whether the ontology is modified in place or a new file is created, and does not mention required permissions or state changes. With no annotations, the description carries the full burden but only partially addresses behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, covers the main purpose first, and provides a clear example for annotation format. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool having 21 parameters and no schema descriptions, the description only explains a small subset. Important aspects like output behavior, error conditions, and workflow are missing, making it incomplete for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only three parameters (annotation, link_annotation, language_annotation) receive some explanation. The remaining 18 parameters (e.g., input, output, remove_annotations) are not described, leaving significant gaps given 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds metadata annotations to an ontology, with specific actions like setting ontology IRI and version IRI. The name 'robot_annotate' is self-explanatory and distinct from sibling tools such as robot_convert or robot_filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like robot_rename or robot_remove. No context about prerequisites or scenarios 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?
No annotations are provided, so the description carries the full burden. It explains the select parameter (controlling which related terms to include) and the trim flag (controlling axiom requirement for ALL or ANY objects). However, it does not disclose whether the tool modifies input in place, requires specific permissions, or any side effects. For a tool with no annotations, the description is somewhat transparent but lacks completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences conveying the core purpose and key parameters. It is front-loaded with the verb and resource. No unnecessary words. However, given the complexity (21 params), a slightly longer description could improve completeness without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 21 parameters, no annotations, and an output schema. The description only covers a fraction (4 parameters) and does not explain the output or provide context for the many boolean flags, file path parameters, or extra_args. For such a complex tool, the description is significantly incomplete, leaving the agent with inadequate information to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains four parameters (term, term_file, select, trim) but leaves 17 out of 21 parameters completely undocumented (e.g., exclude_term, axioms, signature, preserve_structure). The description adds meaning for a few critical params but fails to cover the majority, leaving the agent blind to many options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Selectively copy axioms from an ontology (inverse of remove).' It specifies what it does (copy axioms), the resource (ontology), and distinguishes from sibling tool robot_remove by noting it is the inverse. The mention of parameters (term, term_file, select, trim) further clarifies functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implicit guidance by stating it is the 'inverse of remove,' which hints at when to use it versus robot_remove. However, there is no explicit when-to-use or when-not-to-use guidance, no mention of prerequisites (e.g., input ontology must be specified), and no alternatives listed. Usage is implied but not fully 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?
No annotations are provided, so the description carries the full burden. However, it only says the tool 'materializes inferred superclass relationships using a reasoner' without discussing side effects, permissions, whether it modifies data, or what the output looks like. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences and a usage note. It front-loads the purpose and is efficient, though it could potentially include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, no annotations, and a presence in a large sibling set), the description is incomplete. It lacks details on input/output handling, behavior, and safety, leaving an agent underinformed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 14 parameters, the description only mentions two parameters ('term' and 'term_file') and their purpose. It does not explain the remaining 12 parameters, failing to add meaning beyond the schema's bare structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool materializes inferred superclass relationships using a reasoner, and explicitly distinguishes it from the sibling tool 'reason' by focusing on asserting existential restrictions. This provides a specific verb and resource (materialize superclass relationships) and differentiates it from similar 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance by advising to use 'term' or 'term_file' to restrict which properties to materialize, and notes the similarity to 'reason' but with a different focus. This gives context for when to use the tool, though it does not explicitly state when not to use it or list alternatives beyond the mention of 'reason'.
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 provided. The description explains that it runs a reasoner and controls inferred axioms via axiom_generators, but does not disclose whether the input ontology is modified, permissions needed, or potential side effects. Some behavioral traits are covered, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs with a clear first sentence and a list. It is concise, but the list of reasoners could be more structured. Still, it is brief and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 21 parameters and no schema descriptions, the description only addresses two. It lacks details on input/output handling, ontology creation flags, and other common options. Output schema exists but is not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only explains 'reasoner' (with options) and 'axiom_generators' (with example). The remaining 19 parameters receive no explanation, leaving the agent uncertain about input, output, paths, flags, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs an OWL reasoner to classify and check consistency. The verb 'run' and resource 'OWL reasoner' are specific, and the purpose is distinct from sibling tools like robot_annotate or robot_merge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reasoning tasks but does not specify when to use it over alternatives like robot_materialize or robot_classify. No explicit guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that ROBOT exits with a non-zero code when violations are found (controllable via fail_on_violation), adding value beyond the schema. However, it does not describe other behavioral aspects like output format, file creation (output_dir), or side effects (e.g., whether it modifies the ontology).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and no redundant information. However, it could be restructured to front-load the most critical details (e.g., fact that it checks an ontology, non-zero exit). The current structure is acceptable but not optimized for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, no schema descriptions, no annotations, and an output schema not described), the description is incomplete. It fails to explain the return value, the role of most parameters, or prerequisites (e.g., an ontology must be provided via input or working_directory).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains two parameters (queries and fail_on_violation) out of 13. Critical parameters like input, output_dir, working_directory, prefixes, verbose, strict, etc., are left undocumented, leaving the Agent with insufficient semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks an ontology for rule violations using SPARQL SELECT queries, which is a specific verb+resource. It distinguishes itself from siblings like robot_query (which runs arbitrary queries) and robot_validate_profile (which uses OWL reasoning) by focusing on SPARQL SELECT-based violation detection and non-zero exit on findings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that query files should contain SPARQL SELECT and that results indicate violations, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., robot_query or robot_validate_profile). Usage context is implied but not formally contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the behavioral burden. It explains that the tool downloads ontologies and generates a catalog file, but does not disclose side effects (e.g., file overwriting), required permissions, or performance implications. More detail on the caching process would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences with clear front-loading of purpose. Every word contributes to understanding the core function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a clear purpose, the description omits crucial details for correct usage: behaviors of boolean flags like 'strict' and 'xml_entities', meaning of 'prefixes' and 'add_prefix', and effects of 'extra_args'. With 12 parameters and no annotations, completeness is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It only clarifies 'directory' and 'output' implicitly, but leaves 10 other parameters (e.g., prefixes, add_prefix, strict, extra_args) undocumented, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'mirrors (caches) external ontology imports locally', specifies actions (downloads to directory, generates catalog XML), and distinguishes it from siblings like robot_convert or robot_extract by focusing on offline caching of imports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when network reliability is a concern ('prevents network failures from breaking builds'), but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.
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 takes on the burden of behavioral disclosure. It explains that the tool performs a destructive operation (removing axioms) and describes the motivation (keeping ontology minimal). It does not cover authorization or side effects, but the core behavior is adequately communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with the first sentence immediately stating the primary action. Every sentence provides necessary context (what, why, when), and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has 14 parameters with 0% schema description coverage. The description fails to explain how to use any of the parameters, making it incomplete for an agent to correctly invoke the tool. The purpose is clear, but parameter usage is entirely undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about any of the 14 parameters. It only describes the overall function, leaving the agent with no additional meaning beyond the parameter names and types in the schema. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'redundant subClassOf axioms' with a reasoner. It explains the reasoning process and distinguishes it from siblings like robot_reason (pure reasoning) and robot_remove (generic removal), making the purpose specific and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after reasoning ('After reasoning, some asserted subclass relationships become redundant'), providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives like robot_reason or robot_remove for non-redundancy tasks.
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?
Without annotations, the description indicates a destructive operation (removing axioms) but does not disclose whether the input files are modified, what the output format is, or any side effects like validation or error handling. It is minimally 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and no redundant information. Every word contributes to understanding the main function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no annotations, no output schema details), the description is insufficient. It omits output behavior, error cases, parameter roles, and prerequisites, leaving an AI agent underinformed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 11 parameters, the description only mentions 'input' informally and lacks any explanation of other critical parameters like 'output', 'catalog', 'prefixes', etc. This provides almost no semantic help beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it removes axioms from the first ontology that appear in subsequent ones, using a subtractive operation. It distinguishes itself from siblings like robot_merge and robot_diff by focusing on subtraction rather than combination or comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to provide multiple input files with the first as base and the rest for subtraction. However, it does not specify when to use this tool over siblings like robot_diff or robot_filter, nor does it mention prerequisites or limitations.
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. The description discloses that output contains violations and that ROBOT exits with non-zero code on non-conformance. This is useful but lacks details on side effects, file modification, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a list of profiles. No wasted words, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no parameter descriptions in schema, and no annotations, the description is far from complete. It covers basic purpose and exit code but leaves most of the tool's behavior and configuration unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It mentions profiles but does not map them to the 'profile' parameter or describe other parameters (input, output, etc.). The schema has 12 parameters, none explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks ontology conformance to OWL 2 profiles, lists available profiles (EL, RL, QL, DL, Full), and describes output and exit code behavior. It is specific and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for validating conformance to a profile but does not explicitly state when to use this tool versus siblings like robot_verify or robot_report. No guidance on when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. Mentions query types and storage option (tdb). Missing details on whether queries are read-only unless 'update' is used, and what side effects occur for UPDATE (e.g., irreversible).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively concise (three sentences) and front-loads the purpose. Could be more structured (e.g., bullet list of modes), but current format is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters, no annotations, and an output schema (not described), the description lacks details on return values and output format. It mentions file output (CSV, RDF) but no structure. Incomplete for a query tool where output interpretation is crucial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
18 parameters with 0% schema description coverage; description explains only the main mode parameters (query, queries, output_dir, update, tdb) but not others like input, output, prefixes, extra_args, etc. Insufficient detail for an agent to correctly set all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool executes SPARQL queries against an ontology, and distinguishes it from sibling tools like robot_reason or robot_convert by focusing on querying. The main modes (query, queries, update) are clearly listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use each mode: `query` for file pairs, `queries` with `output_dir` for batch, `update` for modifications. Does not explicitly state when not to use, but differentiation from siblings is implicit.
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 bears full behavioral burden. It discloses the core action (running QC queries and generating reports) and key options (profile, fail_on), but omits side effects, resource implications, or error behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose. It uses two sentences, both informative, with no redundancy. Could slightly benefit from listing key parameters but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks coverage for 16 out of 18 parameters. The complexity of the tool (many options) demands more detail for agents to invoke it correctly without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains two parameters (profile and fail_on) out of 18. Most parameters (e.g., input, output, limit, base_iri) remain entirely unexplained, leaving the agent with minimal semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool runs QC SPARQL checks and generates a violation report with severity levels (ERROR, WARN, INFO) and a fail_on threshold. This clearly distinguishes it from sibling tools like robot_query or robot_validate_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use the tool (for QC checks with customizable profiles) and mentions the fail_on parameter to set exit threshold. However, it does not explicitly state when not to use it or compare with alternatives like validate_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the tool computes explanations and describes modes, but does not disclose potential side effects, output format, or limitations. The description is partially adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no redundant sentences. It front-loads the purpose and uses bullet-like formatting for modes, making it easy to scan. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 16 parameters and no annotations, the description is incomplete. It covers only the core purpose and a couple of parameters. Missing details on other parameters, return value, prerequisites, or how output is structured. An output schema exists but is not used to supplement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source. It explains the 'axiom' parameter with an example and mentions 'mode', but 16 parameters exist; most (reasoner, max, unsatisfiable, etc.) are not described, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes minimal axiom explanations for inferred statements, lists three modes, and provides an example of the axiom parameter syntax. This distinguishes it from sibling tools like robot_reason or robot_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it is useful for debugging classification issues and outlines the three modes (entailment, inconsistency, unsatisfiability). While it implies when to use the tool, it does not provide explicit when-not-to-use guidance or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It reveals that metrics are computed but does not state if the tool is read-only, whether it requires a reasoner for certain sets, or any potential side effects. This is adequate but could be more 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. The list of metric sets and output formats is concise 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 13 parameters, no schema descriptions, and no annotations, the description is too minimal. It covers only the core metrics and format, leaving many important parameters unexplained. The existence of an output schema does not compensate for missing parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only explains 'metrics' and 'format' parameters. The other 11 parameters (input, output, working_directory, etc.) are undocumented in both schema and description, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes ontology metrics (entity counts, axiom counts, complexity). This is a specific verb+resource, and the tool is distinct from siblings like robot_query or robot_reason.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It lists metric sets (essential, extended, etc.) and output formats, guiding when to use different configurations. However, it does not explicitly contrast with sibling tools or provide conditions for using this tool over others.
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 core behavior: converting EquivalentClasses to SubClassOf axioms, making the ontology less restrictive while preserving the subclass hierarchy. With no annotations, this provides sufficient transparency about what the tool does, though it could mention side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the first sentence directly stating the action, the second explaining the transformation, and the third providing pipeline context. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to explain key parameters or provide usage examples. Given the complexity (14 parameters, 0 required, 0% coverage), the description is incomplete for successful invocation, as it omits parameter semantics entirely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the 14 parameters (0% schema coverage). It adds no meaning beyond the input schema, leaving agents without guidance on what parameters like 'input', 'output', or 'exclude_named_classes' do.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('relax equivalence axioms into weaker subclass axioms') and specifies the transformation (EquivalentClasses to SubClassOf). It distinguishes itself from siblings by mentioning its role in a pipeline before reduce.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly describes when to use the tool ('before reduce') and its typical pipeline position ('reason → relax → reduce'). However, it does not provide explicit when-not-to-use scenarios or compare directly to all siblings, which would elevate it to 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 description carries full burden. It states removal is the inverse of filter, implying a destructive operation, but does not disclose potential side effects, irreversibility, or what happens to related axioms or structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with an example. No wasted words, front-loaded with purpose, and uses inline code formatting for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool is complex with 21 parameters. Description fails to explain crucial parameters like 'axioms', 'signature', 'trim', 'preserve_structure', leaving behavioral gaps. Incomplete for a high-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Out of 21 parameters, description only explains three (term, term_file, select). Schema coverage is 0%, so description should compensate but does not explain the majority of parameters, leaving the agent underinformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool removes selected axioms from an ontology, using the verb 'remove' and resource 'axioms'. It explicitly identifies itself as the inverse of filter, distinguishing it from 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on specifying terms via 'term' or 'term_file' and controlling selection with 'select', including an example. Lacks explicit when-not-to-use or alternative sibling guidance, but context is sufficient.
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 explains the template process but lacks disclosure of side effects (e.g., file overwriting, error behavior) or authorization needs. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences. The first sentence states the core purpose; the second adds key structural and usage details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, no schema descriptions), the description is too sparse. It does not cover many crucial parameters or scenarios, even though an output schema exists. Incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only explains two parameters (merge_before, merge_after) and the template structure, leaving 16 other parameters (e.g., input, output, force) undocumented. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts tabular data (CSV/TSV) into OWL ontology format, with a specific verb and resource. This distinguishes it from sibling tools like robot_annotate or robot_convert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the template file structure (row1=headers, row2=template strings) and mentions merge_before/merge_after for controlling combination with input ontology. However, it does not explicitly state when to use this tool versus alternatives like robot_convert for other conversions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It mentions input/output details but does not disclose behavioral traits like read-only nature, side effects, or requirements. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loaded with purpose, and no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters and no annotations, the description covers core functionality but misses many optional parameters. With an output schema present, return values are not needed, but the parameter coverage is insufficient for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains 7 out of 18 parameters (left, right, left_iri, right_iri, output, format, labels) but omits many like catalog, prefixes, verbose, etc., leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Compare two ontologies and report semantic differences', using specific verb and resource. It distinguishes from sibling tools by focusing on comparison, unlike others like robot_merge or robot_remove.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use by specifying input methods (file paths/IRIs) and output formats. However, it does not explicitly state when not to use or provide direct 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 full burden. It mentions conversion between formats, supported file types, and gzip compression via .gz suffix. It does not detail side effects, permissions, or file overwrite behavior, but the core behavior is reasonably 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no redundancy. The first sentence states the purpose, and the second adds essential details on formats and compression, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters and 0% schema coverage, the description is insufficient. It omits explanations for most parameters (e.g., check, working_directory, prefixes). The presence of an output schema is not leveraged, and no return value details are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only explains the 'format' parameter via supported formats and the .gz convention for compression. Many parameters (input, output, check, working_directory, catalog, prefixes, etc.) are left unexplained, forcing the agent to rely on inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts an ontology between formats, with a specific verb and resource. It lists supported formats, distinguishing it from sibling tools that perform other operations (e.g., filter, reason).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for format conversion by naming supported formats and compression. However, it lacks explicit guidance on when not to use it or alternatives, though the sibling tools cover other distinct tasks.
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?
Without annotations, the description carries the burden. It discloses key behavior: by default, import closures are merged and owl:imports statements are removed. However, it does not mention behaviors like annotation handling, prefix options, or output location.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each valuable: tool definition, input specification with examples, and default behavior. No unnecessary words; front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 17 parameters and no schema descriptions, the description should cover more. It adequately explains input methods and default collapse behavior but omits output, working directory, catalog, prefixes, and other essential parameters. The presence of an output schema (context) reduces the need to describe return values, but parameter documentation is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It explains three parameters (input, input_iri, inputs) with usage details and examples. But the remaining 14 parameters (output, collapse_import_closure, include_annotations, etc.) are not explained, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool merges OWL ontology files into a single ontology, specifying the resources (input paths/IRIs) and how to provide them (input, input_iri, inputs). This distinguishes it from siblings like robot_unmerge and robot_collapse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool (combine ontology files) and gives examples of glob patterns. It does not state when not to use or list alternatives, but the context of sibling tools provides differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains in-memory passing, argument mapping rules, and provides examples. It does not mention error handling or side effects, but the behavior is well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with bullet points and code blocks. It front-loads the purpose and provides necessary details without unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and an output schema, the description covers the main functionality and steps usage. It lacks explanations for some optional parameters, but they are straightforward. Overall, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It thoroughly explains the 'steps' parameter structure and argument mapping. Other parameters like working_directory and catalog are not individually explained, but they are standard and less critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes a chain of ROBOT commands in a single process, distinguishing it from sibling tools which are single commands. It specifies the verb and resource precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use (e.g., chaining multiple commands) and notes that only first step needs input, last needs output. It also suggests using 'help':true to discover flags. However, it does not explicitly state when not to use (e.g., for single commands).
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/musen-lab/robot-tool-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server