Skip to main content
Glama

IDDET

mcp_update_community

Met à jour une communauté (admin/modérateur uniquement).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
categoryNo
icon_urlNo
auth_tokenYes
banner_urlNo
descriptionNo
community_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the entire behavioral burden, and it only discloses the admin/moderator permission requirement. It says nothing about whether the update is partial or full-replacement (all optional fields default to null), whether existing values are overwritten, reversibility, or the response shape, which is a substantial 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?

A single front-loaded sentence with zero filler, so it is efficient. For a 7-parameter mutation tool it borders on under-specification rather than being genuinely well-structured, but it wastes nothing.

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?

A mutation tool with no annotations, no output schema, and 7 parameters at 0% coverage needs more than one sentence. The permission note helps, but update semantics, partial-vs-full behavior, and field meaning are all absent, so an agent cannot call it confidently without inspecting the schema.

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

Parameters2/5

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

There are 7 parameters with 0% schema description coverage, so the schema contributes almost no semantics. The description compensates only for the action itself and mentions none of the updatable fields (name, category, icon_url, banner_url, description) or the required auth_token/community_id, leaving parameter meaning essentially undocumented.

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 states a specific verb and resource ('Met à jour une communauté'), which distinguishes it from sibling mutations like mcp_create_community and mcp_delete_community. It does not, however, indicate which attributes (name, category, icon, banner, description) can be updated, so the scope of the update is left to the schema.

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

Usage Guidelines3/5

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

The parenthetical '(admin/modérateur uniquement)' supplies a real access precondition that guides who can invoke it. There is no explicit routing against alternatives such as create vs update, nor any statement of when an update is preferable, so guidance is implied rather than complete.

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