Algenta MCP Server

discover_capability_binding

Discover the capabilities one binding exposes and return them as catalog entries. Pass binding_id to discover a saved binding (this publishes or refreshes its capabilities in the catalog), or a full inline definition to preview-discover one that was never saved. Call this after create_capability_binding, then browse the result with list_capabilities.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "discover_capability_binding"
  }
}

Input Schema

Name	Required	Description
`scope`	No	Scope for the inline preview form.
`config`	No	Credentials/options for the inline preview form.
`scope_ref`	No	Scope reference for the inline preview form.
`binding_id`	No	Saved binding id to discover; omit to preview inline.
`profile_id`	No	Profile id for the inline preview form.
`provider_id`	No	Provider id for the inline preview form.
`execution_owner`	No	Execution owner for the inline preview form.
`customer_metadata`	No	Metadata for the inline preview form.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedSep 23, 2026
- addedInput schema / properties / binding_id / description
```
Added value: +"Saved binding id to discover; omit to preview inline."
```
- addedInput schema / properties / config / description
```
Added value: +"Credentials/options for the inline preview form."
```
- addedInput schema / properties / customer_metadata / description
```
Added value: +"Metadata for the inline preview form."
```
- addedInput schema / properties / execution_owner / description
```
Added value: +"Execution owner for the inline preview form."
```
- addedInput schema / properties / profile_id / description
```
Added value: +"Profile id for the inline preview form."
```
- addedInput schema / properties / provider_id / description
```
Added value: +"Provider id for the inline preview form."
```
- addedInput schema / properties / scope / description
```
Added value: +"Scope for the inline preview form."
```
- addedInput schema / properties / scope_ref / description
```
Added value: +"Scope reference for the inline preview form."
```
First observedJul 12, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The description transparently discloses the side-effect behavior for saved bindings ('this publishes or refreshes its capabilities in the catalog'), which aligns with readOnlyHint=false and idempotentHint=false. It also clarifies that inline definitions are only previewed ('never saved'), adding behavioral nuance beyond the annotations. No contradiction with annotations was found.

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

Conciseness5/5

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

Three sentences, each earning its place: the first states the core outcome, the second contrasts the two usage modes, and the third gives concrete lifecycle context. The most important scoping information is front-loaded, and no filler or redundant wording exists.

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?

The description covers purpose, modes, and workflow but leaves a key gap: it never specifies what constitutes a valid 'full inline definition' (e.g., which of the seven inline fields are required together). With zero required parameters in the schema, an agent could reasonably call the tool with neither binding_id nor an inline definition. The schema's per-field descriptions mitigate but do not close this ambiguity, and there is no output schema to describe the returned catalog entry structure.

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

Parameters4/5

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

Schema description coverage is 100%, providing baseline value. The description goes further by grouping parameters conceptually: binding_id for saved discovery versus the other parameters forming 'a full inline definition' for preview. This mode-level semantics helps an agent understand how to choose among the eight optional parameters without repeating the schema text.

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?

The description states a specific verb and resource: 'Discover the capabilities one binding exposes and return them as catalog entries.' It clearly differentiates the two modes (saved binding via binding_id vs inline preview) and references sibling tools (create_capability_binding, list_capabilities), making its role in the capability lifecycle unmistakable.

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?

The description provides explicit sequencing guidance: 'Call this after create_capability_binding, then browse the result with list_capabilities.' It also explains when to use binding_id versus an inline definitioniciously. However, it does not explicitly distinguish this from test_capability_binding or state when not to use it, so the guidance falls short of a full when/when-not specification.

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

All Algenta MCP Server 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.