Skip to main content
Glama

get_object

Read-only

Full detail for one business object: agent-oriented description, row_count (data rows in its primary export) and grain (the columns that identify one row — null when none was found), fields (each field whose column is in the export with a role — identifier, dimension, measure or attribute, derived from the export, with role_basis naming the rule that gave it — and a profile of counts only: the column type, filled and blank rows, and distinct values, never a value; role and profile are absent where the field was not assessed; and every field with an explicit pii flag and a personal-data classification: category none/contact/identity/financial/special-category/other-personal, where it came from — the column name, the shape of the values as counts, or the customer — and its confidence), source systems, every relation touching it (with strength, join key and row coverage — the share of rows that actually reach the other side), the findings that mention it, and the automations your human’s systems run that read or write it (automations, when the workspace keeps a registry — see list_automations). Fields with pii=true hold personal data — never select or echo their values from source systems unless the task explicitly requires it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesObject name as the map spells it — the name search, route and the object pages hand out, e.g. "invoice" or "Invoice". A name written entirely in lower case is matched too.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / name / description
      Previous value: -"Object name, e.g. \"invoice\""New value: +"Object name as the map spells it — the name search, route and the object pages hand out, e.g. \"invoice\" or \"Invoice\". A name written entirely in lower case is matched too."
  2. First observed

TDQS

A3.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/non-destructive, but the description adds real behavioral context beyond them: profiles are 'counts only ... never a value', PII fields are flagged with classification and confidence, and it states a hard rule not to select or echo PII values from source systems. That is meaningful safety guidance the annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the key clause, but the body is effectively one enormous nested sentence with stacked parentheticals that is difficult to parse and scan. The content is informative but the structure fails conciseness — it should be broken into distinct sentences or a short list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description bears the full burden of describing return values, and it does so thoroughly: fields, roles, profiles, PII classification, relations with strength/join key/coverage, findings, automations, plus a caveat that some sections are absent when not assessed. Minor gaps remain (no guidance on volume/pagination or error behavior for a missing object).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single 'name' parameter is fully documented in the schema, including case-insensitive matching, so the description is not required to carry parameter meaning. The description adds nothing further about the name argument. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Full detail for one business object') and enumerates what 'detail' means — fields, relations, findings, automations. It is distinguishable from get_metric/get_process siblings by naming the returned artifacts, though the runaway sentence structure makes the core purpose harder to extract than it should be.

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: an agent infers this is the drill-down after a map/search or route. There is no explicit when-to-use, when-not, or alternative routing (e.g. versus get_map_overview or list_findings), aside from a passing pointer to list_automations for registry context.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources