Skip to main content
Glama
Sign In

Ogen

by com.ogenhq
OverviewDiscussionsAdmin

Bind a live source

bind_source

New workspace, nothing bound yet — this is the tool to start with. Bind a key to a live, read-only source: a JSON endpoint, a Postgres/Supabase table, an Airtable table, a Google Sheet, a HubSpot object, a tool on another MCP server, a Salesforce SOQL query, a NetSuite SuiteQL query, a one-row SELECT against a raw Postgres database, or a Priority ERP OData read. Every recall reads it fresh — nothing here is cached as truth. Record only.

Input Schema

NameRequiredDescriptionDefault
keyYesThe key to bind.
urlNoFor a plain JSON endpoint: an https:// URL, the live source for this key. Omit when using `source` instead.
fieldNoFor a plain JSON endpoint only: an optional dotted path to one value in the response, e.g. "status" or "data.items.0.total" (object keys or array indexes, up to 16 segments). Recall then answers with just that value. A missing path, a body that isn't JSON, or a null there comes back unavailable with reason field_missing, not_json or field_null, and a detail naming the missing segment. Omit it to get the whole body.
sourceNoInstead of a plain endpoint: a Postgres/Supabase table (postgrest), an Airtable table, a Google Sheet, a HubSpot object, a tool on another MCP server (mcp), a Salesforce SOQL query (salesforce), a NetSuite SuiteQL query (netsuite), a one-row SELECT against a raw Postgres database (postgres) — direct SQL, read-only — or a Priority ERP OData read (priority): base_url, username/password (or Priority's own application credentials, sent the same way), form, filter, field. Fields depend on kind. For salesforce/netsuite/hubspot/airtable/postgrest/postgres/priority, pass connection: "<name>" (see connections action "set") instead of that kind's own credential fields.
headersNoFor a plain JSON endpoint only: optional request headers (e.g. an auth token), up to 16. Stored encrypted at rest.
alongsideNoBind a SECOND (or third, or fourth) live source to this key instead of replacing the one it already has. When the bound systems disagree, the act holds and whoever decides sees every reading, labelled by system. Omit this (the default) to replace the key's one source, removing any other source already bound alongside it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / alongside
      Added value: +{
+  "description": "Bind a SECOND (or third, or fourth) live source to this key instead of replacing the one it already has. When the bound systems disagree, the act holds and whoever decides sees every reading, labelled by system. Omit this (the default) to replace the key's one source, removing any other source already bound alongside it.",
+  "type": "boolean"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / headers / description
      Previous value: -"For a plain JSON endpoint only: optional request headers (e.g. an auth token). Stored encrypted at rest."New value: +"For a plain JSON endpoint only: optional request headers (e.g. an auth token), up to 16. Stored encrypted at rest."
  3. Changed1 schema field changed
    • changedInput schema / properties / source / description
      Previous value: -"Instead of a plain endpoint: a Postgres/Supabase table (postgrest), an Airtable table, a Google Sheet, a HubSpot object, a tool on another MCP server (mcp), a Salesforce SOQL query (salesforce), a NetSuite SuiteQL query (netsuite), a one-row SELECT against a raw Postgres database (postgres) — direct SQL, read-only — or a Priority ERP OData read (priority): base_url, username/password (or Priority's own application credentials, sent the same way), form, filter, field. Fields depend on kind. For salesforce/netsuite/hubspot/airtable/postgrest/postgres/priority, pass connection: \"<name>\" (see set_connection) instead of that kind's own credential fields."New value: +"Instead of a plain endpoint: a Postgres/Supabase table (postgrest), an Airtable table, a Google Sheet, a HubSpot object, a tool on another MCP server (mcp), a Salesforce SOQL query (salesforce), a NetSuite SuiteQL query (netsuite), a one-row SELECT against a raw Postgres database (postgres) — direct SQL, read-only — or a Priority ERP OData read (priority): base_url, username/password (or Priority's own application credentials, sent the same way), form, filter, field. Fields depend on kind. For salesforce/netsuite/hubspot/airtable/postgrest/postgres/priority, pass connection: \"<name>\" (see connections action \"set\") instead of that kind's own credential fields."
  4. Changed1 schema field changed
    • addedInput schema / properties / field
      Added value: +{
+  "description": "For a plain JSON endpoint only: an optional dotted path to one value in the response, e.g. \"status\" or \"data.items.0.total\" (object keys or array indexes, up to 16 segments). Recall then answers with just that value. A missing path, a body that isn't JSON, or a null there comes back unavailable with reason field_missing, not_json or field_null, and a detail naming the missing segment. Omit it to get the whole body.",
+  "type": "string"
+}
  5. First observed

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description does disclose important behavior: the source is read-only, every recall reads fresh with no caching, and 'Record only' implies binding does not itself fetch data. However, it omits credential/auth expectations, whether connectivity is validated at bind time, failure behavior, and idempotency/replacement semantics (though some of this is covered in the schema rather than the description).

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 description is front-loaded with the use case, then the action, then a compact enumeration of source kinds. The trailing 'Record only.' is terse to the point of ambiguity and the long source list is somewhat dense, but overall there is little wasted text.

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?

Given a rich 100%-covered input schema with no output schema, the description provides the essential context: what the tool binds, supported source types, read semantics, and initial-workspace usage. It leaves some operational details, such as auth requirements and bind-time validation, to the schema or to inference, so it is strong but not fully self-contained.

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 description coverage is 100%, so the schema already documents each parameter, including kind-specific fields, header encryption, and the alongside replacement rule. The description restates the source kinds already represented in the source.kind enum but adds no parsing or format guidance beyond what the schema provides.

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 description states a specific verb and resource ('Bind a key to a live, read-only source') and enumerates every supported source kind, so the action is unambiguous. It does not name the sibling tool an agent should use for reading (recall_live_fact), so sibling differentiation is implied rather than explicit.

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?

'New workspace, nothing bound yet — this is the tool to start with' gives a clear triggering context for when to call this tool. It does not explicitly state when not to use it or name the alternative tools for reading or connection setup, leaving that inference to the agent.

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

All Ogen toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources