Skip to main content
Glama

Register an agent target

create_target

Register an agent you own or are authorized to test as a target for security assessments. Supply exactly one of: 'config' (the connection config of an endpoint that answers without a key: one live probe fires and the target is saved only if it succeeds); 'url' (a page of yours that your agent's chat lives on: a headless browser discovers the agent behind it, returning status=discovering and a discovery_token to poll with get_target_discovery, or status=not_a_page when the url is already an API endpoint, then supply it as a 'config'); or 'discovery_token' (plus 'candidate' when get_target_discovery listed more than one) to save a discovered candidate, whose session stays on the server. A rejected URL or a failed probe stores nothing and returns a categorized error (invalid_url / unreachable / auth_failed / parse_error / no_reply / not_an_endpoint). This tool asks for no keys, tokens or passwords: an agent that needs one is added in the Enoki app at https://app.enokilabs.ai/inventory (Add integration), which is also the fix for an auth_failed probe on an agent that needs one. Call get_setup_guide first for the workflow and the config field reference. Check list_targets first (a matching name + endpoint_host in the same environment is the same target, so reuse its model_id; if only one of them matches, confirm with your user before creating). A target's connection has no update or delete over MCP; change it in the Enoki app. Its profile is read and changed with get_target_profile and update_target_profile. The response never echoes your config. Requires the write scope; the full setup flow also needs read, for get_setup_guide and list_targets.

Input Schema

NameRequiredDescriptionDefault
urlNoA page of yours that your agent's chat lives on, to discover the agent behind it.
nameNoDisplay name for the target; required with 'config' or 'discovery_token'.
configNoThe endpoint's connection config (endpoint_url, response_field, transport, ...); its fields are in get_setup_guide and the create_target_schema resource.
candidateNoIndex of the discovered candidate to save, when there is more than one.
environmentNoWhere the agent runs.staging
discovery_tokenNoId of the discovery job a create_target call with 'url' started.

Output Schema

NameRequiredDescriptionDefault
statusYes'created' when a target was saved, 'discovering' for a page, 'not_a_page' when the url is an endpoint to supply as a config.
messageNoHuman-facing note.
model_idNoThe target's id, when status=created.
connectedNoWhether the probe read a reply.
discovery_tokenNoPoll it with get_target_discovery, when status=discovering.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses probe behavior, discovery polling, conditional saving, categorized errors, permission requirements, and the fact that the response never echoes config. This is unusually rich behavioral context for a write operation.

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 and every sentence carries useful information, but the long branching sentence for the three input modes is dense and could be easier to scan. It remains appropriately sized for a multi-mode registration tool.

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?

Given the complex conditional workflow, the output schema, and full schema coverage, the description is complete enough to call correctly. It covers workflow entry points, failure behavior, permissions, follow-up tools, and why no credentials are accepted.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds critical cross-parameter semantics: exactly one of config/url/discovery_token, plus needing 'candidate' only when discovery lists multiple candidates. It also explains the required name relationship and the conditional role of url versus config.

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 opens with a specific verb and resource: 'Register an agent ... as a target for security assessments.' It also names sibling tools such as list_targets, get_setup_guide, get_target_discovery, and get_target_profile, making its role distinct.

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

Usage Guidelines5/5

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

It gives explicit branching guidance for the three mutually exclusive inputs: 'config', 'url', or 'discovery_token'. It also names alternatives and prerequisites directly, including 'Call get_setup_guide first' and 'Check list_targets first'.

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