FavCRM

create_outlet

Create a shop outlet/location. Optionally pass id to preserve a legacy UUID during migration.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	Optional outlet UUID (for legacy migration; non-standard formats accepted)
`name`	Yes	Outlet name
`phone`	No	Contact phone
`address`	No	Street address
`logoUrl`	No	Logo URL
`isActive`	No	Whether outlet is active (default true)
`latitude`	No	Latitude
`longitude`	No	Longitude
`sortOrder`	No	Display sort order (default 0)
`acceptsOrders`	No	Whether outlet accepts online orders (default true)

Output Schema

TableJSON Schema

Name	Required	Description
`data`	Yes	Tool result payload — shape varies per tool, see the tool description
`summary`	Yes	One-line human-readable summary of the action
`renderType`	Yes	UI rendering hint for the result

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedJun 8, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations readOnlyHint=false properly align with 'Create' as a write operation, with no contradiction. The description adds useful context about preserving a legacy UUID during migration, but does not disclose other behavioral aspects like duplicate handling or error cases. Since idempotentHint=false and an output schema exist, the description need not cover everything.

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?

Two short sentences, with the primary action front-loaded and the optional id behavior clarified in the second. Every word contributes, with no fluff or repetition.

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 full input schema, output schema, and annotations, the description is complete enough for an agent to select and invoke the tool. The migration note covers the one non-obvious option, while the structured metadata handles parameter details and return values.

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?

The input schema has 100% coverage with descriptions for all 10 parameters, so the description carries little burden here. The note about preserving a legacy UUID adds some meaning for the id parameter, but the schema already mentions legacy migration and non-standard formats, so added value is minimal.

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?

Description opens with 'Create a shop outlet/location', using a specific verb and resource. This clearly distinguishes it from sibling tools like update_outlet and list_outlets, as well as other create_* tools.

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

Usage Guidelines4/5

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

It explicitly states when to pass the optional id: 'during migration' to preserve a legacy UUID. This gives clear context, though it does not mention alternatives or exclusions. Given there is no close sibling, this is sufficient guidance.

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

All FavCRM tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.3/5.0

Disambiguation2/5

Many tools have overlapping boundaries, such as generate_post_cover/attach_post_cover_from_job/upload_post_cover_from_url, update_deal/update_deal_stage/mark_deal_won/mark_deal_lost, and booking status transitions (confirm/cancel/complete/mark_no_show). The catch-all execute_tool adds further ambiguity.

Naming Consistency4/5

Nearly all tools follow a consistent verb_noun snake_case convention (create_*, list_*, get_*, update_*, delete_*, restore_*). Minor exceptions like 'clone' and 'execute_tool' are still readable and do not significantly break the pattern.

Tool Count1/5

With 223 tools, the server is extremely over-scoped. Even for a full CRM platform, this many tools overwhelms context windows and makes tool selection impractical. It far exceeds the reasonable range for an MCP server.

Completeness3/5

The surface is broad but has notable gaps: no update_booking/delete_booking, no delete_product, no send_message/send_campaign (referenced but absent), and no delete_staff/resource. Some workflows dead-end or require manual approval steps.

create_outlet

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources