Skip to main content
Glama
Sign In

goldseam

by com.ksaworks
OverviewDiscussionsAdmin

Look Up Word

look_up_word
Read-only

What does this one word reach? Answers the word as a card: its meanings (each with its definition and part of speech), its family of attested forms and the catalog's own use of it, its KSA placement or its relations, its SOC and CIP codes strongest evidence first (each with every way that reached it and the counts behind it), its ONET elements by official id, its ONET Technology Skills, Tools Used and Detailed Work Activity entries under plain labels with ONET's own names, codes and releases in the detail, its ESCO occupations and skills through the ESCO–ONET crosswalk, and GoldSeam's next tools by code. Every code carries its official links (O*NET OnLine, BLS, NCES, ESCO). Every call, found or not, returns the step-by-step report of the ten stages it read. Spread is a label, never a penalty. resolve_term is unchanged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "word": "<word>"
    },
    "name": "look_up_word"
  }
}

Input Schema

NameRequiredDescriptionDefault
wordYesOne word, as written, e.g. negotiate or fundraising

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.2/5.0
Behavior4/5

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

Annotations only supply readOnlyHint=true, so the description carries most of the burden and does add real value: every call returns a ten-stage step-by-step report whether or not the word is found, spread is explicitly a label rather than a penalty, and every code carries official links. These are behaviors an agent could not derive from the schema or annotations. It does not cover latency, rate limits or failure modes, keeping it off 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The body is one enormous run-on sentence that strings a dozen return categories together with no separators, and it ends with an unrelated note about resolve_term. The opening question is well front-loaded, but the remainder is a wall of undifferentiated enumeration that is hard to scan. Significant trimming into a short purpose sentence plus a bulleted return summary would improve it.

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?

There is no output schema, so the description must describe returns, and it does so exhaustively down to code links and O*NET release metadata. For a complex multi-source lookup tool this is close to complete on the output side. The remaining gap is operational: nothing tells the agent when this is the right call versus the sibling lookup tools.

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?

Schema description coverage is 100% for the single 'word' parameter, with examples already in the schema, so the baseline of 3 applies. The description reinforces 'one word' and 'as written' but adds no formatting, casing or normalization rules beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb and resource: it answers a single word as a 'card' enumerating meanings, attested forms, KSA placement, SOC/CIP codes, O*NET elements, ESCO occupations and next tools. That is unmistakably more specific than the name alone. It stops short of 5 because the only nod to siblings, 'resolve_term is unchanged,' is a changelog remark rather than a statement of how this differs from resolve_term or expand_term.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance, and no stated condition that would send an agent to resolve_term, expand_term or crosswalk_code instead. The line 'Spread is a label, never a penalty' is interpretive behavior, not routing guidance. An agent must infer selection from the sibling names alone.

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

All goldseam toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources