Skip to main content
Glama

Get custom model capabilities

get_custom_model_capabilities
Read-only

Explain the supported Bring Your Own Model (BYOM) adapters, credential handling, HTTPS and SSRF restrictions, and inability of a public remote MCP server to connect directly to localhost. Use before configuring a custom model. Returns capability metadata without contacting a model, starting a trial, or consuming a send.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly=true, openWorld=false, destructive=false. The description adds valuable context beyond that: it explains it 'Returns capability metadata without contacting a model, starting a trial, or consuming a send,' which tells the agent there's no side effect or cost. The credential/HTTPS/SSRF content is informational scope rather than behavior, but the no-contact/no-cost guarantee is a genuine addition.

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?

Two sentences, front-loaded with the purpose and followed by usage guidance and behavior. The enumeration of restrictions is slightly dense but each item is relevant.

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?

For a zero-parameter read-only tool with annotations covering safety, the description does enough: it explains what it returns (capability metadata), when to use it, and that there's no side effect. No output schema, but the description notes it returns metadata, which is sufficient.

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?

Zero parameters, so baseline is 4. The description correctly implies this is a no-argument informational tool; nothing to document.

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?

States a specific verb (explain) and resource (BYOM adapter capabilities, restrictions), and enumerates what it covers: adapters, credential handling, HTTPS/SSRF, localhost limitation. Clearly distinguishable from run_custom_model and validate_custom_model siblings.

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?

Explicitly says 'Use before configuring a custom model,' giving a clear when-to-use cue. Doesn't name exclusions or alternative tools like validate_custom_model, but the pre-configuration context is clear.

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