Skip to main content
Glama

Attach a connector to a website

attach_site_connector
Idempotent

Attach an organization connector to a website so pages served from that site can call the connector's tools.

Attaching is a grant, and it is wider than it looks: every person who can open the page can call every tool the connector exposes, using the credential Valet holds for it. On a private site that is every member of the organization; on a password-protected or shared one it is everyone holding the password or the link. Valet does not narrow the connector's reach for a page, so attach only what the page needs and check the site's access mode before you do.

Only an organization connector that is an HTTP MCP server — transport sse or streamable-http — can be attached; list_attachable_connectors reports exactly that set. A connector that belongs to a single agent cannot back a page. A page calls the connector by its own name, which is what list_site_connectors reports and what the page's request path carries. Attaching a connector that is already attached changes nothing and is safe to repeat. Requires connecting a Valet account.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteYesRequired. The site's name.
org_nameNoThe Valet organization the site and the connector belong to. Omit to use the organization the account joined first.
connectorYesRequired. The organization connector's name. It is also the name a page served from the site calls it by.

TDQS

A4.7/5.0
Behavior5/5

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

The description substantially expands on the annotations by explaining the grant-like nature of attaching, the security implications of who can call tools, and the fact that Valet does not narrow the connector's reach per page. It also explicitly confirms idempotency, matching the idempotentHint annotation.

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?

The description is front-loaded with the core action and then builds necessary security and constraint context. Every sentence carries meaningful information; there is no filler or repetition.

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 mutation tool with annotations and no output schema, the description is complete. It covers prerequisites, eligibility, security caveats, idempotency, and how to discover attachable connectors, leaving no critical gap for an agent to call the tool correctly.

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 baseline is 3. The description adds context about connector eligibility and that the connector name is used by pages, but the parameter-level meaning is already well documented in the schema itself.

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: attach an organization connector to a website, with a clear outcome (pages can call the connector's tools). It further distinguishes itself from siblings by stating that only HTTP MCP server connectors can be attached and that list_attachable_connectors reports exactly that set.

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?

The description gives explicit guidance on when to attach and what to check beforehand, including the site's access mode and attaching only what the page needs. It also states exclusions (single-agent connectors cannot be used) and names list_attachable_connectors as the way to identify eligible connectors.

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.

TDQS

A4.3/5.0
Disambiguation5/5

Every tool pairs a distinct resource with one action: site, connector, catalog, design system, access, and sharing are separate concerns. The four list_* tools are clearly differentiated by object (sites, site connectors, attachable connectors, catalog connectors), and attach/detach, publish/rename/delete, and set/share are unambiguous.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern with no stray camelCase or inconsistent verb styles. The naming is predictable: list_X for discovery, get_X for single reads, create_/delete_/rename_/attach_/etach_ for lifecycle actions, and set_/ share_/ call_ for specific operations.

Tool Count4/5

At 16 tools the server is slightly over the ideal 3-15 range, but each tool addresses a distinct part of the site-publishing and connector-attachment workflow. None feel redundant, and the set remains navigable despite being a bit dense.

Completeness4/5

The site lifecycle is essentially complete: publish, read, list, rename, set access, share, and delete, with updates supported through republishing. The connector lifecycle covers discovery, creation, attachment, listing, calling, and detach, but there is no connector update/delete or share-revocation tool, which are minor gaps agents can work around.

Resources