Skip to main content
Glama
Moe03

Convocore MCP Server

by Moe03

agency_write

Destructive

Create or delete an agency account with upsert or deletion actions; branding, domain verification, and org/client management are handled separately.

Instructions

Create (upsert with a name) or delete the agency account. To brand it (logo, colour, fonts, language, login page, assets) use agency_branding instead — it validates fields. Domain claims, verification flags, secrets and provider keys cannot be changed here (domains are verified on the dashboard). For org/client CRUD use orgs_write / clients_write.

Input Schema

NameRequiredDescriptionDefault
actionYes
agencyNoAgency fields for upsert (passthrough object).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.6.17

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds useful behavior beyond them: upsert requires a name, branding fields are validated elsewhere, and certain fields are immutable here. It does not describe return values or deletion permanence, but annotations already flag destructive behavior.

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 uses the remaining sentences for high-value routing and field constraints. Every sentence earns its place, with no redundant restatement of the tool name or annotations.

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 the destructive annotation and absence of an output schema, the description covers purpose, alternatives, and key field restrictions well. The main remaining gap is that the nested agency payload is still not fully described, though the critical field exclusions are stated.

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 coverage is 50%, and the description clarifies that the action supports upsert/delete and that upsert needs a name. However, the agency object is a passthrough with a vague schema description, and the description lists what cannot be changed rather than enumerating allowed agency fields.

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 gives a specific verb and resource: create/upsert or delete the agency account. It clearly distinguishes this tool from agency_branding, orgs_write, and clients_write, so an agent can identify its role without opening schemas.

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 explicitly routes branding work to agency_branding and org/client CRUD to orgs_write / clients_write. It also states exclusions such as domain claims, verification flags, secrets, and provider keys, which are not changeable here.

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

Deploy Server

Other Tools