Skip to main content
Glama
msweeney-pnnl

eplusout-mcp

by msweeney-pnnl
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

search_html_tables_by_keyword

Find specific EnergyPlus simulation tables by searching keywords like 'cooling', 'heating', or 'energy' in table names and metadata. Filter HTML output to locate relevant results quickly.

Instructions

Search for HTML tables containing specific keywords in their names.

Filters available HTML tables based on keyword matches in table names, report names, or other metadata. Useful for finding specific types of tables like 'cooling', 'heating', 'energy', etc.

Args: id: The model_id of the EnergyPlus model (obtain from get_available_models). keywords: List of keywords to search for (e.g., ['cooling', 'coil', 'capacity']) case_sensitive: Whether to perform case-sensitive search (default: False)

Returns: Dictionary containing: - matching_tables: List of tables that match the keywords - search_keywords: The keywords that were searched for - total_matches: Number of matching tables found - search_stats: Statistics about the search - model_id: The model identifier

Examples: # Find cooling-related tables search_html_tables_by_keyword(model_id, ['cooling', 'coil'])

# Find energy consumption tables
search_html_tables_by_keyword(model_id, ['energy', 'consumption'])

# Case-sensitive search for specific terms
search_html_tables_by_keyword(model_id, ['DX', 'VAV'], case_sensitive=True)

Common Keyword Categories:

Energy & Consumption: ['energy', 'consumption', 'end use', 'site energy', 'source energy', 'electricity', 'natural gas', 'fuel', 'annual', 'monthly', 'utility', 'cost', 'performance']

Cooling Systems: ['cooling', 'coil', 'capacity', 'chiller', 'dx cooling', 'sensible cooling', 'latent cooling', 'peak cooling', 'cooling tower', 'evaporative cooler', 'refrigeration']

Heating Systems: ['heating', 'boiler', 'heat pump', 'heating coil', 'heat recovery', 'sensible heating', 'peak heating', 'furnace', 'baseboard', 'radiant heating', 'heat exchanger']

HVAC Components: ['fan', 'pump', 'air loop', 'plant loop', 'zone equipment', 'terminal unit', 'ahu', 'air handler', 'vav', 'cav']

Building Envelope: ['window', 'wall', 'roof', 'floor', 'construction', 'material', 'thermal bridge', 'infiltration', 'ventilation']

Lighting & Equipment: ['lighting', 'electric equipment', 'gas equipment', 'occupancy', 'schedule', 'internal load', 'plug load']

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
keywordsYes
case_sensitiveNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries the behavioral disclosure burden. It covers how matching works (keyword matches in table names, report names, or other metadata), the case_sensitive default behavior, and the full return structure. It could additionally state that this is a read-only/search operation, but the described behavior is otherwise transparent.

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?

The description is well-structured with clear sections: summary, args, returns, examples, and keyword categories. The common keyword categories are lengthy but genuinely useful for an agent choosing search terms. It is longer than minimal, but the content is organized and mostly earns its place.

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?

With no output schema present, the description compensates by listing the exact return dictionary fields. It also documents all parameters, gives multiple usage examples, and provides domain-specific keyword guidance. An agent has everything needed to call the tool correctly and interpret its result.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must fully explain the parameters. It does: id is tied to get_available_models, keywords are defined with concrete examples, and case_sensitive is explained with its default. This adds substantial meaning beyond the bare input schema.

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 states a specific verb and resource: 'Search for HTML tables containing specific keywords in their names.' It also clarifies the matching scope (table names, report names, or metadata) and includes examples, making the tool's purpose unmistakable and distinct from siblings like get_html_table_by_tuple.

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 gives clear usage context: it is 'useful for finding specific types of tables like cooling, heating, energy, etc.' and provides examples. It does not explicitly contrast this tool with alternatives such as get_html_table_by_tuple or execute_pandas_on_html_table, so it stops short of full when-to-use-versus-other-tools guidance.

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