Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

createRedirect

Create a 301 redirect rule to preserve SEO after URL path changes, with automatic checks for duplicate and conflicting rules to prevent redirect loops.

Instructions

Create a redirect - Create a new 301 redirect rule.

Use when: preserving SEO after any URL change - slug rename on a member profile, post, page, or category. BD auto-creates some redirects on its own (admin-triggered renames), but you must create them manually for API-triggered changes. Avoid duplicate old_filename values.

Required: old_filename, new_filename.

type is wrapper-managed: the wrapper hardcodes type=custom on every create. The other BD type values (profile, post, category) are reserved for BD's own auto-redirect logic on admin-triggered renames and are not exposed here.

Pre-check before create - TWO checks (redirects are uniquely dangerous: wrong rules cause infinite loops and SEO damage):

Check 1 - exact-pair skip (idempotent): Do a server-side filter-find: listRedirects property=old_filename property_value=<proposed old> property_operator==. If a row exists where new_filename also matches the proposed new, skip the create - the rule is already there; creating a duplicate just bloats the redirect table. If a row exists with the same old_filename but a DIFFERENT new_filename, that's a conflict: reuse via updateRedirect with the new target, OR ask the user which destination wins. Never silently create a duplicate or conflicting old_filename.

Check 2 - reverse-rule loop prevention (CRITICAL): Do a second filter-find: listRedirects property=old_filename property_value=<proposed NEW> property_operator==. If a row exists where new_filename equals your proposed old_filename, creating this rule would produce an infinite redirect loop (A->B and B->A). STOP. Flag to the user, explain the reverse rule in place, and ask whether to delete the existing reverse rule first or abandon the create.

Do NOT paginate unfiltered redirect lists - filtered lookups are two tiny responses. On any site with a large redirect history, dumping the full table wastes rate limit and context.

Parameter interactions:

  • old_filename / new_filename - URL paths relative to the domain root (not full URLs)

  • db_id - database record ID of the source content if the redirect ties to one; otherwise 0

See also: updateRedirect (modify existing).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
old_filenameYesThe old URL path being redirected from, relative to the domain root (e.g. old-slug, not the full URL)
new_filenameYesThe new destination URL path
db_idNoDatabase record ID of the source content object this redirect was generated from (0 if not tied to a record)
idNoLegacy secondary identifier; typically 0 for system-generated redirects
Behavior5/5

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

Describes behavioral traits beyond annotations: dangerous side effects (infinite loops, SEO damage), wrapper-managed type, and the need for two pre-checks. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

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?

Well-structured with sections and bold emphasis, but somewhat long. Every sentence adds value, so it earns a high score despite length.

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?

Comprehensive given the tool's complexity and danger. Covers required params, pre-checks, parameter interactions, and usage context. No output schema, but creation tools typically don't need return value explanation.

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

Parameters4/5

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

Schema has 100% coverage, but the description adds context: relative URL paths, db_id as optional source ID, and id as legacy. This goes beyond the schema, warranting a score above baseline 3.

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?

The description clearly states the tool creates a 301 redirect rule and specifies its use for preserving SEO after URL changes. It distinguishes itself from siblings like updateRedirect by focusing on creation.

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?

Explicit guidance on when to use (API-triggered changes vs. BD auto-created), what to avoid (duplicate old_filename), and detailed pre-check steps with alternative actions (skip, update, or warn). Also references updateRedirect as an alternative.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/brilliantdirectories/brilliant-directories-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server