Skip to main content
Glama

mcp-server

Create task link

muovi_create_task_link
Read-onlyIdempotent

Build a link that opens Muovi's own task creation for one professional and one service: pass the id of a result from muovi_search_professionals as professional_id, and a service slug from muovi_list_services. Any professional in the search results can be picked. When the person publishes the task, it goes to that professional first for 24 hours and then opens to everyone; on the form the person can choose to also receive offers from other professionals right away. The link opens Muovi's task form, not the professional's ProSite. This tool makes no network call and saves nothing: give the URL to the person, who completes the task on Muovi.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
service_slugYesThe service slug to start the task with (from `muovi_list_services`).
professional_idYesThe `id` of a professional from `muovi_search_professionals`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / professional_id
      Added value: +{
      +  "description": "The `id` of a professional from `muovi_search_professionals`.",
      +  "maxLength": 36,
      +  "minLength": 36,
      +  "type": "string"
      +}
    • removedInput schema / properties / professional_slug
      Removed value: -{
      -  "description": "The professional's URL-safe slug (from `muovi_search_professionals` or `muovi_get_professional`).",
      -  "minLength": 1,
      -  "pattern": "^[a-z0-9][a-z0-9.\\-]*$",
      -  "type": "string"
      -}
    • changedInput schema / properties / service_slug / description
      Previous value: -"The service slug to pre-fill in the task flow (from `muovi_list_services`)."New value: +"The service slug to start the task with (from `muovi_list_services`)."
    • changedInput schema / properties / service_slug / pattern
      Previous value: -"^[a-z0-9][a-z0-9.\\-]*$"New value: +"^[a-z0-9][a-z0-9_-]{0,63}$"
    • changedInput schema / required
      Previous value: -[
      -  "professional_slug",
      -  "service_slug"
      -]New value: +[
      +  "professional_id",
      +  "service_slug"
      +]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare readOnly, idempotent, non-destructive, but the description goes far beyond by disclosing no network call and nothing saved, and by explaining the 24-hour exclusivity window and the option to receive other offers immediately. This is meaningful behavioral context an agent cannot get from annotations.

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 core action and then layers workflow and business rules efficiently. Slightly dense with multiple clauses, but every sentence earns its place and there is no redundancy.

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 two-parameter link builder with no output schema, the description covers inputs, workflow, business logic, and the no-side-effect guarantee. An agent has everything needed to call it and hand off the result 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 coverage is 100% and both parameters are already documented with source references in the schema. The description reinforces the source tools but adds no new syntax or format detail beyond what the schema provides, so baseline 3 is appropriate.

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?

Starts with a clear verb and resource ('Build a link') and immediately scopes it to task creation for one professional and one service. It explicitly distinguishes itself from the ProSite and from the sibling draft tool by explaining the link opens Muovi's own task form.

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?

Tells the agent exactly which sibling outputs to feed in: professional_id from muovi_search_professionals and service_slug from muovi_list_services. Also clarifies the workflow — give the URL to the person who completes the task on Muovi — and states no network call is made.

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.