Skip to main content
Glama

object_rows

Retrieve instances of a specified object type from a saved run, with pagination (20 per page) or all at once.

Instructions

一个对象在数据里的每一个实例,一页 20 个;all=true 一次给全部。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "saved_as": "<saved_as>",
      "type": "<type>"
    },
    "name": "object_rows"
  }
}

Input Schema

NameRequiredDescriptionDefault
allNotrue 一次给全部,不分页
pageNo第几页,从 1 起
typeYes对象的 key,来自 list_objects
saved_asYes运行的保存名,来自 list_runs 或 build_ontology

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
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 behavioral burden. It usefully discloses the page size of 20 and that all=true returns everything at once, but it does not describe the shape of the returned rows, the default page, or the risk of using all=true on large objects.

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 definition is two terse, front-loaded clauses separated by a semicolon, with no filler. It may be slightly under-specified for a tool with pagination, but nothing in it is wasted.

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 four-parameter paginated read with complete schema coverage and no output schema, this definition is adequate but thin. It leaves open how results are ordered, what page defaults to, and how large an object all=true can return safely, all of which an agent would need in order to call the tool 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 schema description coverage is 100%, and the definition already documents all four parameters, so the baseline score is 3. The description repeats what is already in the schema (the 20-item page size and the effect of all=true) without adding page defaults or constraints on type or saved_as beyond where those values come from.

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 definition states a specific resource and scope: every instance (row) of one object in the data, at 20 per page. An agent can tell this returns data rows rather than field metadata, so object_fields is distinct, but the definition never distinguishes this tool from find_instances.

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 only implied: call this tool when you want the instances of an object. It gives no explicit guidance on when to prefer this over find_instances or instance_neighbourhood, nor any prerequisites, though the description does state that all=true bypasses paging.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.