Skip to main content
Glama
inakirealise

BoondManager MCP Server

by inakirealise

boond_agencies_create

Create a new agency in BoondManager by providing a name, plus optional city, address, and country to establish a record.

Instructions

Create a new agency

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNo
nameYes
addressNo
countryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. 'Create a new agency' only states the basic action; it does not disclose potential side effects, permission requirements, irreversibility, or data validation behavior. This is a significant gap for a mutation tool.

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 a single, clear sentence with no wasted words. It is front-loaded and compact, earning its place by stating the core purpose. However, it is perhaps too sparse, as it sacrifices helpful detail for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description does not adequately prepare the agent to use the tool correctly. It does not explain required parameters (e.g., 'name' is mandatory), expected return values, or error handling. The tool is relatively simple, but the description still leaves many contextual gaps.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no information about the parameters (name, city, address, country). It does not compensate for the missing schema documentation, leaving the agent to infer parameter meaning solely from names. This is insufficient for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new agency' clearly identifies the action (create) and the resource (agency), distinguishing it from sibling tools like boond_agencies_search, get, and update. However, it does not provide any additional scoping or special meaning beyond the tool name, so it lacks the specificity that would warrant a 5.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention that this is for inserting a new agency rather than updating an existing one, nor does it reference sibling tools for different operations. Usage must be inferred entirely from the tool name.

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