Skip to main content
Glama
Sign In

Oxford Ledge

by com.oxfordledge
OverviewDiscussionsAdmin

Glossary Term

ol_glossary_term
Read-only

Oxford Ledge's editorial GLOSSARY: ~1,500 finance and investing terms written for lifelong students of the market -- definition, worked example, etymology, pronunciation, related terms (see-also), and the learning paths that teach the concept. Look up one term by name (case and punctuation tolerant: 'first lien', 'convexity', 'duration'). Use it to ground explanations in the SAME definitions the platform teaches from, instead of improvising one. Source: Oxford Ledge editorial (reviewed in-house); FREE.

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": {
      "term": "<term>"
    },
    "name": "ol_glossary_term"
  }
}

Input Schema

NameRequiredDescriptionDefault
termYesThe term to look up, e.g. 'duration'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

readOnlyHint=true already tells the agent this is a safe read; the description adds real value beyond that by disclosing the corpus size (~1,500 terms), the in-house editorial provenance, that access is FREE, and the case/punctuation tolerance of the lookup. It doesn't describe pagination or fallback behavior when a term isn't found, which is the only remaining gap.

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?

Front-loads the resource and its scope before the usage rationale, and every sentence carries information the agent can act on. It's slightly verbose in the marketing-flavored clause ('written for lifelong students of the market'), but nothing is redundant with the schema.

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, the description carries the return-value burden and does so by enumerating the fields a lookup returns plus the educational metadata (see-also, learning paths). For a single-parameter read tool with annotations covering safety, nothing essential is missing.

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% for the single parameter, so the baseline is 3; the description goes beyond the schema by specifying normalization behavior ('case and punctuation tolerant') with concrete examples ('first lien', 'convexity', 'duration') that signal multi-word and no-punctuation inputs are valid.

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 resource (Oxford Ledge's editorial glossary of ~1,500 finance/investing terms) and enumerates exactly what a lookup yields: definition, worked example, etymology, pronunciation, related terms, and learning paths. No sibling tool touches editorial glossary content, so the tool is unambiguously distinguishable from the screener/data siblings.

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?

Explicitly frames the use case ('ground explanations in the SAME definitions the platform teaches from, instead of improvising one'), which tells the agent both when to reach for it and what behavior it replaces. It stops short of naming a competing tool or an exclusion condition, but no sibling offers an alternative glossary, so the guidance is effectively complete.

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

All Oxford Ledge 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