Skip to main content
Glama
rudeayelo

aimharder-mcp

by rudeayelo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

execute_activity_publication

Publishes the exact activity preview after rechecking source, account preferences, and role permissions, and enforces the confirmation policy before a single POST with no automatic retry.

Instructions

Publish the exact fresh activity preview. Recheck source, account preferences and current hosted role permission before at most one POST, then read the own calendar/detail. An uncertain result is never retried automatically. Read writeConfirmationRequired from preparation. Account context exposes separate bookingCreation and activityPublication settings in writeConfirmationPolicy; cancellation and deletion always require confirmation. When true, show the exact preview and obtain separate account-holder confirmation before execution with confirmed: true. When false, an explicit request for this exact action is sufficient; omit confirmed and do not ask for another confirmation. A query or preview-only request never authorizes execution.

Input Schema

NameRequiredDescriptionDefault
gymIdNo
confirmedNo
actionReferenceYes
acknowledgePossibleDuplicateNo

Output Schema

NameRequiredDescriptionDefault
statusYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.3
    • changedInput schema / required
      Previous value: -[
-  "actionReference",
-  "confirmed"
-]New value: +[
+  "actionReference"
+]
  2. Addedv0.4.1

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only say non-read-only, open-world, non-idempotent, non-destructive; the description adds permission rechecks, single-POST/no-automatic-retry behavior, and detailed confirmation policy including writeConfirmationRequired. It also notes that cancellation and deletion always require confirmation, which is useful policy context.

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?

Front-loads the action and then packs in behavior and confirmation rules with no obvious filler. It is still long and dense for one tool, so it is effective but not maximally concise.

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

Completeness3/5

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

Output schema and annotations cover return values and safety, and the description gives rich behavioral guidance. However, with 0% schema description coverage, missing explanations for two parameters leaves the agent without enough parameter context for a complex write action.

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?

The schema has four parameters with 0% description coverage. The description explains `confirmed` semantics and implies `actionReference` comes from the prepared preview, but it never explains `gymId` or `acknowledgePossibleDuplicate`, leaving key parameter meanings missing.

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?

Names a specific verb ('Publish') and resource ('exact fresh activity preview'), and frames it as execution after a prepared preview. This distinguishes it from prepare_activity_publication and query/preview siblings.

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?

Gives explicit execution gates: recheck source, preferences, and role; perform at most one POST; never retry an uncertain result. It clearly states that query or preview-only requests do not authorize execution and spells out the true/false confirmation branches.

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