Fetch the immediate child terms of an OLS ontology term to traverse its class hierarchy one level at a time. Enables step-by-step ontology exploration.
List the direct children of an OLS term. Use this to walk an ontology's class hierarchy one level at a time.
| Name | Required | Description | Default |
|---|---|---|---|
| iri | Yes | Full IRI of the parent term. | |
| size | No | Max children to return. | |
| ontology_id | Yes | Ontology identifier (e.g. 'envo'). |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that it returns only *direct* children (non-recursive, one level), which is real behavioral information, but it says nothing about read-only safety, pagination/truncation from the size cap, ordering, or failure modes for an invalid IRI.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero waste, with the core action ('list direct children') front-loaded. Nothing repetitive or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 carry more of the contract. It conveys the essential return (direct children) but omits the shape of a child entry and, critically, what happens when the size cap is reached, which matters for a traversal tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so iri, ontology_id, and size are all documented in the schema itself. The description adds only the implicit notion that iri is the parent term; it adds no format, syntax, or edge-case guidance beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the direct children of an OLS term') and scopes it to one level of an ontology hierarchy. It is clear what the tool returns, though it does not name the sibling (mesa_ols_get_term) it is adjacent to, so an agent must infer the boundary from the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this to walk an ontology's class hierarchy one level at a time' gives a concrete usage context: iterative traversal of a hierarchy. It does not name explicit alternatives (e.g. mesa_ols_get_term for a single term, or mesa_ols_search_terms), so there are no stated exclusions, but the intended scenario is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.