Skip to main content
Glama
Sign In
math-board

math-board

by smdesai27
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Search illustrations

board_library
Read-only

Search ~2,000 offline Bioicons for anatomy, cells, microbes, DNA, plants, animals, and lab equipment; returns icon IDs for science illustrations and lists categories when no query is given.

Instructions

Search the offline science illustration library (~2000 Bioicons: anatomy, organs, cells, blood and immunology, microbes, viruses, DNA, plants, animals, lab equipment). Returns icon ids for an artifact {type:'icon', icon:id, x, y, width}. No query lists the categories.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "board_library"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoDefault 25
queryNoKeywords, e.g. 'heart cross section'
categoryNoCategory substring

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered; the description adds real context beyond that: the library is offline, it contains ~2000 items across named domains, and results are icon ids intended for an artifact {type:'icon', ...}. It doesn't mention result caps beyond the schema's default limit.

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 dense sentences, front-loaded with purpose and scope, then the return contract and the empty-query behavior. No filler and nothing repeated from the schema.

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?

With no output schema, the description usefully specifies the return contract (icon ids and the artifact snippet shape), which is the key missing piece. It leaves minor gaps such as how limit interacts with large result sets and whether category and query are combined.

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 coverage is 100%, so baseline is 3, and the description adds meaning the schema does not: an omitted query enumerates categories rather than returning nothing. It doesn't clarify whether category and query combine or how substring matching behaves beyond the schema's own note.

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?

States a specific verb and resource ('Search the offline science illustration library') with concrete scope (~2000 Bioicons and the content domains covered). It also states the return shape (icon ids for an artifact), so an agent can distinguish it from the board_* siblings at a glance.

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?

'No query lists the categories' gives an explicit fallback browsing path when the agent has no keywords, which is genuine when-to-use guidance. It does not spell out when to prefer category vs query filtering, and only implicitly contrasts with siblings (all board_* tools are clearly different).

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