Retrieve all instances of a specified object type from the ontology. Provide the object type's API name to get matching records, with an optional limit.
지정한 Object Type의 인스턴스를 조회한다. object_type은 list_object_types의 api_name.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| object_type | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
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 burden of disclosing behavior. It indicates a read/query operation ('조회한다') but does not mention pagination, limits, error behavior, or what the output contains. Minimal behavioral detail beyond the verb itself.
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?
One tightly worded sentence with the key scoping information front-loaded. No filler or redundant restatement of the schema.
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?
The output schema exists, so return values are structurally covered. Still, the description lacks guidance on limit semantics and does not clarify the relationship with sparql_query, leaving an agent partially guessing about invocation parameters and tool choice.
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 0%, so the description must compensate. It adds meaningful semantics to object_type by tying it to list_object_types.api_name, but it leaves limit entirely unexplained, despite limit having a default of 20 and obvious behavioral importance.
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?
The description states a specific action (retrieve instances) and a specific resource (instances of a designated Object Type), and it clarifies that object_type is the api_name from list_object_types, which helps distinguish it from that sibling. It does not explicitly contrast with sparql_query, so it is not a full 5.
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?
The description provides a key usage prerequisite: object_type must be an api_name from list_object_types, implying the agent should call that sibling first. However, it gives no explicit guidance on when to choose this tool over sparql_query 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.