Capable

Update object type

update_object

DestructiveIdempotent

Admin-only patch of a custom object's label, plural, blurb, icon, shared-write mode, enabled flag or display_field (null resets to name). show_in_menu changes navigation only; hiding a menu row leaves the object usable. Built-in keys accept only enabled and show_in_menu. enabled:false hides records across the workspace and makes generic verbs refuse the object until re-enabled; nothing is deleted. Preview first, then confirm:true to disable; enabling needs no confirmation. describe_schema.switchable identifies objects that allow switching; foundational objects and feature parts do not. Returns the definition, or key and changes for a built-in/menu-only update.

When to use: An admin reconfigures an object type or its menu visibility.

Example: Rename the Property object to Listing.

Input Schema

Name	Required	Description
`key`	Yes	The object's stable key (from describe_schema). On a built-in key only enabled and/or show_in_menu apply; any other change is refused.
`icon`	No	A key from Capable's curated object-icon set (e.g. landmark, factory, handshake, flask); an unknown key is rejected with suggestions. Null clears back to the neutral default.
`blurb`	No	New one-sentence description of the object; null clears it.
`label`	No	New singular display name. The key does not change.
`plural`	No	New plural display name for lists and the menu.
`shared`	No	true lets any non-viewer edit every record of this object; false lets only the record's owner, admins and managers edit it.
`confirm`	No	Required (true) to turn a BUILT-IN object off: the first enabled:false call answers with a preview instead. Not needed for anything else.
`enabled`	No	false turns the object off (it leaves the schema and menu and the generic verbs refuse it; records kept); true turns it back on. On a built-in key, false needs confirm:true after a preview call.
`show_in_menu`	No	Whether the object appears in the web app's sidebar menu — an explicit per-object override of the bounded default. Navigation only: it never changes what the object can do (that is `enabled`). Composes with the other args on a custom key; on a built-in key only with enabled.
`display_field`	No	The data key holding a record's display name (a lowercase field key); null resets to the "name" default.

Output Schema

Name	Required	Description	Default
`key`	No
`note`	No
`label`	No
`object`	No
`updated`	No
`requires_confirm`	No
`records_affected_note`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 24, 2026

removedInput schema / properties / blurb / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / blurb / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedInput schema / properties / display_field / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / display_field / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedInput schema / properties / icon / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / icon / type

Added value: +[
+  "string",
+  "null"
+]

Changed1 schema field changedOct 20, 2026
- removedInput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
Changed4 schema fields changedOct 19, 2026
- removedOutput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
- removedOutput schema / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / object / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / object / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```

Changed2 schema fields changedOct 19, 2026

changedInput schema / properties / enabled / description

Previous value: -"false turns the object off — it leaves the schema and menu and the generic verbs refuse it, records kept; true turns it back on. On a built-in key, false needs confirm:true (the first call previews); custom objects switch as before."New value: +"false turns the object off (it leaves the schema and menu and the generic verbs refuse it; records kept); true turns it back on. On a built-in key, false needs confirm:true after a preview call."

changedInput schema / properties / show_in_menu / description

Previous value: -"Whether the object appears in the web app's sidebar menu — an explicit per-object override of the bounded default. NAVIGATION only: it never changes what you or the app can do with the object (that's `enabled`). Composes with the other args on a custom key; on a built-in key it composes only with enabled."New value: +"Whether the object appears in the web app's sidebar menu — an explicit per-object override of the bounded default. Navigation only: it never changes what the object can do (that is `enabled`). Composes with the other args on a custom key; on a built-in key only with enabled."

First observedOct 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond destructiveHint/idempotentHint: it states that enabled:false hides records but deletes nothing, that generic verbs refuse the object until re-enabled, that menu hiding is navigation-only, that custom vs built-in keys allow different field sets, and that disabling requires a preview then confirm:true while enabling does not. These are exactly the mutation consequences an agent cannot infer from the annotations.

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?

Front-loads the mutation scope, then behavioral rules, then when-to-use and an example – a sensible order with no filler. It is dense with long compound sentences, but nearly every clause carries distinct operational information.

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

Completeness5/5

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

For a 10-parameter destructive admin mutation, the description covers authorization (admin-only), side effects, the preview/confirm sequence, built-in-key limits, and even a brief return-value hint despite an output schema existing. Nothing an agent needs to call it safely is missing.

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%, so the schema already documents every parameter including null-resets, confirm, and the built-in key restriction. The description restates much of that (display_field null resets to name, built-in keys accept only enabled/show_in_menu) but adds limited new per-parameter meaning, so baseline 3 applies.

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

Purpose5/5

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

Opens with a specific verb+resource ('Admin-only patch of a custom object') and enumerates exactly which attributes can change, separating custom keys from built-in keys. The custom-vs-built-in split and the display_field/menu distinction make it unambiguous against siblings like define_object.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

An explicit 'When to use' line plus a concrete rename example give the agent a clear trigger, and describe_schema.switchable is named as the eligibility check. It stops short of explicitly routing to an alternative (e.g. define_object for creation, update_record for records), so it is strong but not complete.

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

All Capable tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?