Explore public CD, money-market, Treasury and municipal rate records with data dates and source links. Compare options and build illustrative fixed-income ladders. No BrinkerAdvisor account or API key required. Public information only; no account access, trading or personalized investment advice. Documentation: https://mcp.brinkeradvisor.com/support
Scored across 5 tools
search and mention_rates both appear to search current public rate records, and mention_rates' description ('desktop composer resource picker') does not clearly explain how it differs from general search. The boundaries between search, fetch, and compare_rates are otherwise well described, and build_ladder is distinct.
The set mixes verb_noun names (build_ladder, compare_rates, mention_rates) with bare verbs (fetch, search). This remains readable, but it is not a consistent naming convention across all tools.
Five tools is well-scoped for a read-only rate research server. Discovery, detail retrieval, comparison, ladder construction, and picker support are each handled by a separate tool.
The core read-only workflows for current public CD, money-market, Treasury, and municipal rates appear covered: search/list, fetch by ID, compare, and build a ladder. Minor gaps include no bulk fetch by multiple IDs and no explicit institution-listing tool, though search can work around both.
Build an educational equal-weight maturity ladder from current eligible public CD, money-market, Treasury, or municipal options for a requested rung count and term range. Every covered rung contains a canonical brinkeradvisor_url and an original source_name and source_url. Returns explicit uncovered rungs. This tool does not access accounts, trade, recommend a product, forecast rates or the economy, or provide suitability or tax advice.
| Name | Required | Description | Default |
|---|---|---|---|
| rung_count | Yes | ||
| instrument_types | Yes | ||
| maximum_term_months | Yes | ||
| minimum_term_months | Yes | ||
| hypothetical_amount_usd | No |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | Feed publication date; each covered rung has its own record date and age. |
| rungs | Yes | |
| limitations | Yes | |
| source_freshness | Yes | Feed age band, not the age of every covered rung. |
| illustrative_only | Yes | |
| equal_target_percentage | Yes | |
| hypothetical_amount_usd | Yes | |
| maturity_spacing_months | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are present but thin (readOnlyHint=false, openWorldHint=true, idempotent=false, destructive=false), so the description adds real value: it specifies that each covered rung carries a canonical brinkeradvisor_url plus original source_name/source_url, that uncovered rungs are returned explicitly, and that the tool never touches accounts or trades. It does not mention latency, rate limits, or data freshness for 'current' options. No contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the core action and scope, with the return-shape detail and disclaimers following. Little waste, though the URL/source sentence duplicates information the output schema already conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter tool with an output schema, the description conveys the input semantics, the coverage guarantee of the result, and the ethical/scope boundaries. The remaining gaps are the unexplained optional hypothetical_amount_usd and absent units, which the schema enforces but does not explain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It does cover rung count, term range, and the four instrument types in prose, which maps to four of five parameters, but it never mentions hypothetical_amount_usd (the only optional field) and gives no units or bounds (months, USD limits) beyond what the schema enforces.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (build) plus a precisely scoped resource (an educational, equal-weight maturity ladder from current eligible public CD/money-market/Treasury/municipal options). An agent can distinguish it from a rate-comparison or search tool. It stops short of naming any sibling or stating what it is not relative to compare_rates/fetch, so it lands at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the inputs ('for a requested rung count and term range') and by the negative scope disclaimers (no account access, no trading, no advice), which help route away from trading/advisory tools. However there is no explicit when-to-use trigger and no named alternative, so the agent must infer the conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a bounded side-by-side comparison for an explicit comparison or contrast of current CD, money-market, Treasury, or municipal options with instrument and maturity filters. Returns applied filters, current options, and comparability limitations without selecting a winner. Every option contains a canonical brinkeradvisor_url and an original source_name and source_url. A request merely to find or list several matching records is outside this tool's comparison intent. Economic or Federal Reserve forecasts, account actions, personalized advice, tax advice, and suitability are outside this tool's scope.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| instrument_types | No | ||
| maximum_term_months | No | ||
| minimum_term_months | No |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | Feed publication date; each option has its own record date and age. |
| options | Yes | |
| applied_filters | Yes | |
| source_freshness | Yes | Feed age band, not the age of every option. |
| comparison_limitations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=false, openWorldHint=true, destructiveHint=false. The description adds real context beyond them: what is returned (applied filters, current options, comparability limitations), that no winner is selected, and that each option carries a canonical brinkeradvisor_url plus original source_name/source_url. It does not explain the side effects implied by the non-read-only, non-idempotent hints, which is the one remaining ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose, output contents, and exclusions are front-loaded in a useful order, and the density is justified by the tool's breadth. It is longer than needed at the tail, where two separate sentences restate that things are outside the tool's scope, and the closing exclusion list is somewhat enumerative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value details are optional, yet the description still summarizes the payload (applied filters, options, comparability limitations, attribution URLs), which is helpful. Scope and exclusions are thorough. The only material gap is the undocumented limit parameter, given 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning, and it only partly does: 'instrument and maturity filters' loosely maps to instrument_types and the two term-months bounds. The limit parameter (1-20, default 10) is never mentioned, nor are units or inclusive/exclusive bounds for the term range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: 'Create a bounded side-by-side comparison' of four named instrument classes with instrument and maturity filters. It explicitly excludes a use case ('a request merely to find or list several matching records is outside this tool's comparison intent'), which separates it from listing-style siblings like search. An agent can identify the tool's job without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
When-to-use is explicit ('an explicit comparison or contrast' request) and when-not is well covered (find/list requests, economic or Fed forecasts, account actions, personalized advice, tax advice, suitability). It never names the alternative sibling tools (search, mention_rates, build_ladder) that should handle the excluded cases, so routing is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve complete yield, term, freshness, canonical link, and original-source provenance for one current public BrinkerAdvisor record when its exact stable record ID is already supplied. Requires one known ID and returns one record. The top-level url is the canonical BrinkerAdvisor link; metadata.source_url is the distinct original-source link.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | Absolute canonical BrinkerAdvisor record URL, distinct from the original provider source URL. |
| text | Yes | |
| title | Yes | |
| metadata | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the write/open-world/idempotency profile, so the bar is lower. The description adds real scope context — only 'current public' records, exactly one record — and clarifies the canonical vs. original-source link distinction. It says nothing about behavior when an ID is unknown or stale, or about error/rate-limit behavior, so it is adequate rather than rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the action and resource, then the precondition, then the field-level clarification. Dense but each sentence adds something; the field enumeration is slightly list-like but serves the return-value semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be re-explained, yet the description still adds the canonical-vs-source URL semantics. Combined with the ID precondition and single-record guarantee, an agent has enough to call it correctly; only the failure path for unknown IDs is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the parameter's meaning, and it does: the single id is a 'stable record ID' that must be 'exact' and already known. That tells the agent the input is a previously obtained identifier rather than a query string, though it gives no format or example value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and a specific resource ('one current public BrinkerAdvisor rate record'), and enumerates the returned dimensions (yield, term, freshness, canonical link, provenance). It doesn't name a sibling explicitly, but the 'when its exact stable record ID is already supplied' clause cleanly separates it from search, so an agent can distinguish it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the precondition for use ('when its exact stable record ID is already supplied', 'Requires one known ID') and the cardinality ('returns one record'), which implicitly tells the agent to use search first when no ID is known. No sibling is named as an alternative and there is no explicit exclusion, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search current public rate records for the desktop composer resource picker.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds essentially nothing behavioral beyond that – no hint on result limits, ranking, pagination, or whether 'public' implies an unauthenticated lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with no filler. The tradeoff is that its brevity comes from under-specification rather than disciplined editing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required. However, with an undocumented query parameter and no routing guidance against four siblings, the definition is only minimally complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required 'query' parameter has 0% schema description coverage and the description never explains what the query matches (rate names, geography, service type) or its format. A 300-character maxLength constraint is the only guidance, and that comes from the schema, not the text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a verb+resource ('Search current public rate records'), but the qualifier 'for the desktop composer resource picker' is obscure UI jargon that doesn't sharpen the meaning. Nothing distinguishes it from siblings like search or compare_rates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No statement of when to use this versus compare_rates, search, or fetch, despite three plausible overlapping siblings. The only scoping signal is 'public' and 'current', which is implied rather than explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find or list one or more current public BrinkerAdvisor CD, money-market, Treasury, or municipal rate records by product, institution, term, or maturity when no exact stable record ID is supplied. Discovery of several matching records returns a list, not a side-by-side comparison. Returns stable IDs, titles, and absolute canonical BrinkerAdvisor URLs. Economic indicators or forecasts, unemployment, inflation, GDP, Federal Reserve or central-bank policy, news, general macroeconomic research, account access, transactions, personalized advice, tax advice, and suitability are outside this tool's scope.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description does not need to repeat safety behavior. It adds that discovery returns a list rather than a comparison and mentions stable IDs and URLs, but it does not cover rate limits, authentication, or pagination, leaving moderate gaps beyond what annotations already say.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a long, dense block with a front-loaded core action followed by a scope exclusion list. It is appropriately sized for a search tool but the exclusion enumeration is heavy and some sentences could be folded without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-shape detail is not required, and the description helpfully notes it returns stable IDs, titles, and URLs. However, with one parameter at 0% schema coverage and no sibling differentiation, the definition is adequate but missing enough query semantics and routing guidance to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single query parameter, so the description must compensate. It describes what kinds of filters are possible (product, institution, term, maturity) and notes the 1-300 character limit indirectly, but does not explain syntax, free-text versus structured query, or field separators, leaving meaningful ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a broad verb (find/list) and resource (rate records) with some scoping detail, but the single-token name 'search' does not distinguish it from siblings like fetch or compare_rates. The description explains what it returns (stable IDs, titles, URLs), yet the core retrieval purpose is not crisply separated from other tools in the set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implicitly signals use when no exact stable record ID is supplied, which is useful, but it does not explicitly name alternatives like compare_rates or fetch or state when not to use this tool. The exclusion list clarifies scope but does not guide tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
build_ladder2 fields changedOutput schema / properties / rungs / items / properties / option / properties / term_months / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "null"
- }
-]Output schema / properties / rungs / items / properties / option / properties / term_months / typeAdded value: +[
+ "number",
+ "null"
+]compare_rates2 fields changedOutput schema / properties / options / items / properties / term_months / anyOfRemoved value: -[
- {
- "type": "number"
- },
- {
- "type": "null"
- }
-]Output schema / properties / options / items / properties / term_months / typeAdded value: +[
+ "number",
+ "null"
+]compare_rates2 fields changedInput schema / properties / instrument_types / defaultAdded value: +[
+ "cd",
+ "money_market",
+ "treasury",
+ "municipal"
+]Input schema / requiredRemoved value: -[
- "instrument_types"
-]mention_ratesbuild_ladder2 fields changedOutput schema / properties / rungs / items / properties / option / properties / brinkeradvisor_url / descriptionPrevious value: -"Absolute canonical BrinkerAdvisor record URL. The final answer must display this URL as a clickable link."New value: +"Absolute canonical BrinkerAdvisor record URL, distinct from the original provider source URL."Output schema / properties / rungs / items / properties / option / properties / source_url / descriptionPrevious value: -"Absolute original provider or government source URL. The final answer must distinguish this provenance link from the BrinkerAdvisor record link."New value: +"Absolute original provider or government source URL documenting the record's provenance."compare_rates2 fields changedOutput schema / properties / options / items / properties / brinkeradvisor_url / descriptionPrevious value: -"Absolute canonical BrinkerAdvisor record URL. The final answer must display this URL as a clickable link."New value: +"Absolute canonical BrinkerAdvisor record URL, distinct from the original provider source URL."Output schema / properties / options / items / properties / source_url / descriptionPrevious value: -"Absolute original provider or government source URL. The final answer must distinguish this provenance link from the BrinkerAdvisor record link."New value: +"Absolute original provider or government source URL documenting the record's provenance."fetch2 fields changedOutput schema / properties / metadata / properties / source_url / descriptionPrevious value: -"Absolute original provider or government source URL. The final answer must distinguish this provenance link from the BrinkerAdvisor record link."New value: +"Absolute original provider or government source URL documenting the record's provenance."Output schema / properties / url / descriptionPrevious value: -"Absolute canonical BrinkerAdvisor record URL. The final answer must display this URL as a clickable link."New value: +"Absolute canonical BrinkerAdvisor record URL, distinct from the original provider source URL."search1 field changedOutput schema / properties / results / items / properties / url / descriptionPrevious value: -"Absolute canonical BrinkerAdvisor record URL. The final answer must display this URL as a clickable link."New value: +"Absolute canonical BrinkerAdvisor record URL, distinct from the original provider source URL."build_ladder5 fields changedOutput schema / properties / as_of / descriptionAdded value: +"Feed publication date; each covered rung has its own record date and age."Output schema / properties / rungs / items / properties / option / properties / as_ofAdded value: +{
+ "description": "Original record value date, which may precede the feed publication date.",
+ "type": "string"
+}Output schema / properties / rungs / items / properties / option / properties / data_age_hoursAdded value: +{
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Age of this record, not the feed, when retrieved."
+}Output schema / properties / rungs / items / properties / option / requiredPrevious value: -[
- "id",
- "instrument_type",
- "issuer_or_institution",
- "product",
- "term",
- "term_months",
- "published_yield",
- "source_name",
- "source_status",
- "source_url",
- "brinkeradvisor_url"
-]New value: +[
+ "id",
+ "instrument_type",
+ "issuer_or_institution",
+ "product",
+ "term",
+ "term_months",
+ "published_yield",
+ "as_of",
+ "data_age_hours",
+ "source_name",
+ "source_status",
+ "source_url",
+ "brinkeradvisor_url"
+]Output schema / properties / source_freshness / descriptionAdded value: +"Feed age band, not the age of every covered rung."compare_rates5 fields changedOutput schema / properties / as_of / descriptionAdded value: +"Feed publication date; each option has its own record date and age."Output schema / properties / options / items / properties / as_ofAdded value: +{
+ "description": "Original record value date, which may precede the feed publication date.",
+ "type": "string"
+}Output schema / properties / options / items / properties / data_age_hoursAdded value: +{
+ "anyOf": [
+ {
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Age of this record, not the feed, when retrieved."
+}Output schema / properties / options / items / requiredPrevious value: -[
- "id",
- "instrument_type",
- "issuer_or_institution",
- "product",
- "term",
- "term_months",
- "published_yield",
- "source_name",
- "source_status",
- "source_url",
- "brinkeradvisor_url"
-]New value: +[
+ "id",
+ "instrument_type",
+ "issuer_or_institution",
+ "product",
+ "term",
+ "term_months",
+ "published_yield",
+ "as_of",
+ "data_age_hours",
+ "source_name",
+ "source_status",
+ "source_url",
+ "brinkeradvisor_url"
+]Output schema / properties / source_freshness / descriptionAdded value: +"Feed age band, not the age of every option."build_laddercompare_ratesfetchsearch
Add one secure layer between your agents and this server.