penelope-mcp

Official

Overview Schema Source Related Servers Discussions Admin

search_topics

Find telemetry topics by name with substring matching and case-insensitive search. Get sample counts and units to locate data for your car telemetry questions.

Instructions

Find telemetry topics by name. Start here for any data question.

Substring match, case-insensitive, order-independent: "volt" finds every topic containing "volt", and "pack temp" finds "BMS/Pack Temp". Each hit reports how many samples exist over the topic's whole lifetime (0 means declared but never logged) and its unit when known.

Read three fields before trusting the list:

total_matches vs returned -- broad words match hundreds of topics. When truncated is true you are seeing a page, not the answer. Pass offset (or the next_offset from the last response) to page through the rest; ordering is stable, so pages never repeat or skip a topic.
namespaces -- where the matches live, e.g. most "volt" hits are per-cell topics under BMS/PerCell. Search a longer prefix to narrow.
mode -- all-terms is a real hit. any-term and fuzzy mean nothing matched properly and these are near misses to offer the user.

If more than one hit could plausibly answer the user's question, ask the user to choose rather than picking one yourself.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`car`	No
`limit`	No
`query`	Yes
`offset`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 7, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description reveals return fields (total_matches, truncated, namespaces, mode) and their importance, including subtle behaviors like near misses. It does not mention side effects or rate limits, but for a search operation this is acceptable.

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?

The description is well-organized with a clear lead sentence followed by a bulleted list of important caveats. It is detailed without being redundant, and the structure makes it easy to scan.

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?

The description gives an agent enough context to invoke the tool correctly and interpret results, including when to disambiguate with the user. It lacks explicit mention of the 'car' parameter, but the overall usage pattern is clear.

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 description explains query and offset semantics (substring matching, paging) but leaves car and limit unexplained. Since the schema has no property descriptions, these two parameters remain underspecified, giving roughly 50% parameter coverage.

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 finds telemetry topics by name, with a specific verb and object. It also positions it as a starting point for data questions, making its primary use obvious.

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 instructs to start here for any data question and advises asking the user when multiple plausible hits exist. It also provides guidance on handling pagination and interpreting near misses, though it does not explicitly contrast with sibling tools.

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

Deploy Server