Skip to main content
Glama

add_pattern_restriction

Apply regex pattern restrictions to IDS specification parameters to enforce data format compliance in buildingSMART Information Delivery Specifications.

Instructions

Add pattern restriction (regex matching).

Args: spec_id: Specification identifier or name facet_index: Index of facet in location (0-based) parameter_name: Which parameter to restrict (e.g., "value") base_type: XSD base type (e.g., "xs:string") pattern: Regular expression pattern ctx: FastMCP Context (auto-injected) location: "applicability" or "requirements" (default: "requirements")

Returns: {"status": "added", "restriction_type": "pattern", "spec_id": "S1"}

Example: Add pattern to attribute value: Name must match "EW-[0-9]{3}"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
spec_idYes
facet_indexYes
parameter_nameYes
base_typeYes
patternYes
locationNorequirements

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The async handler function that implements the add_pattern_restriction tool logic. It retrieves the specification, locates the facet, creates a pattern restriction using ids.Restriction, applies it to the specified parameter, and returns a status dictionary.
    async def add_pattern_restriction(
        spec_id: str,
        facet_index: int,
        parameter_name: str,
        base_type: str,
        pattern: str,
        ctx: Context,
        location: str = "requirements"
    ) -> Dict[str, Any]:
        """
        Add pattern restriction (regex matching).
    
        Args:
            spec_id: Specification identifier or name
            facet_index: Index of facet in location (0-based)
            parameter_name: Which parameter to restrict (e.g., "value")
            base_type: XSD base type (e.g., "xs:string")
            pattern: Regular expression pattern
            ctx: FastMCP Context (auto-injected)
            location: "applicability" or "requirements" (default: "requirements")
    
        Returns:
            {"status": "added", "restriction_type": "pattern", "spec_id": "S1"}
    
        Example:
            Add pattern to attribute value: Name must match "EW-[0-9]{3}"
        """
        try:
            ids_obj = await get_or_create_session(ctx)
            spec = _find_specification(ids_obj, spec_id)
    
            await ctx.info(f"Adding pattern restriction to {spec_id}, facet {facet_index}")
    
            # Get the facet
            facet = _get_facet_from_spec(spec, location, facet_index)
    
            # Create pattern restriction using IfcTester
            # Normalize base type (remove 'xs:' prefix if present)
            normalized_base = _normalize_base_type(base_type)
            restriction = ids.Restriction(
                base=normalized_base,
                options={"pattern": pattern}
            )
    
            # Apply restriction to the parameter
            _apply_restriction_to_facet(facet, parameter_name, restriction)
    
            await ctx.info(f"Pattern restriction added: {pattern}")
    
            return {
                "status": "added",
                "restriction_type": "pattern",
                "spec_id": spec_id,
                "facet_index": facet_index,
                "parameter": parameter_name,
                "pattern": pattern
            }
    
        except ToolError:
            raise
        except Exception as e:
            await ctx.error(f"Failed to add pattern restriction: {str(e)}")
            raise ToolError(f"Failed to add pattern restriction: {str(e)}")
  • Registration of the add_pattern_restriction tool handler in the FastMCP server instance.
    mcp_server.tool(restrictions.add_pattern_restriction)
Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses the tool adds restrictions (implying mutation) and shows the return format, but lacks details about permissions needed, whether changes are reversible, error conditions, or rate limits. The behavioral disclosure is adequate but not comprehensive.

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?

Perfectly structured and appropriately sized: purpose statement first, then organized Args section, Returns, and Example. Every sentence earns its place with zero waste, and information is front-loaded effectively.

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 tool's complexity (6 parameters, mutation operation) and no annotations, the description does well with parameter explanations and includes output schema info. However, it could better explain the relationship between parameters (e.g., how facet_index relates to spec_id) and provide more behavioral context for a mutation tool.

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?

With 0% schema description coverage, the description compensates well by explaining all 6 parameters in the Args section with clear examples (e.g., 'parameter_name: Which parameter to restrict (e.g., "value")', 'location: "applicability" or "requirements"'). It adds substantial meaning beyond the bare schema, though some parameter relationships could be more explicit.

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 specific action ('Add pattern restriction') and resource ('regex matching'), distinguishing it from siblings like add_bounds_restriction or add_enumeration_restriction. The example further clarifies it's for restricting attribute values with regex patterns.

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?

The description provides clear context about when to use this tool (adding regex pattern restrictions to specifications), and the example shows a specific use case. However, it doesn't explicitly state when NOT to use it or name alternatives among siblings like add_enumeration_restriction for non-regex constraints.

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/vinnividivicci/ifc-ids-mcp'

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