Skip to main content
Glama
monroedean

doctor-of-credit-mcp

by monroedean
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

doctor-of-credit-mcp

People researching bank bonuses, credit-card offers, and other deals published by Doctor of Credit must currently browse and interpret individual articles themselves. The source material contains valuable details: eligibility restrictions, expiration dates, direct-deposit requirements, geographic limits, and update history. But those details are expressed as prose and can change over time. AI clients need a dependable way to discover and retrieve that source material without losing provenance or presenting inferred details as facts.

Run locally

Requires Node.js 22 or newer.

npm install
npm run build
npm start

The process communicates using MCP over stdio. Configure an MCP client to run node /absolute/path/to/doctor-of-credit-mcp/dist/cli.js.

The server currently provides:

  • list_categories() retrieves every category from Doctor of Credit's WordPress API.

  • get_post(url_or_id) retrieves a post by its positive integer WordPress ID or HTTPS Doctor of Credit article URL.

  • get_post_comments(post_id, page?) retrieves one chronological page of approved public comments for a positive integer WordPress post ID. page defaults to 1.

  • get_post_comment_manifest(post_id, normalization_version?) retrieves a body-free digest manifest for every comment page. The optional normalization version must be doctor-of-credit-comments-v1.

  • get_recent_comments(after, before, page?) retrieves one chronological page of approved public comments published inside a required ISO timestamp window. after must be earlier than before, and page defaults to 1.

  • get_recent_posts(category?, limit?) retrieves recent posts from WordPress, optionally filtered by a category slug returned by list_categories. The default limit is 10 and the maximum is 100.

  • search_posts(query, category?, after?, limit?) searches WordPress article text and titles. category accepts a slug from list_categories, after accepts an ISO calendar date (YYYY-MM-DD) and excludes older publications, and limit defaults to 10 with a maximum of 100.

  • compare_offers(post_ids[]) retrieves between 1 and 10 unique posts by positive integer WordPress ID. It returns each article independently under posts and does not merge or infer offer terms. If some posts cannot be retrieved, successful articles remain available and each failure is reported with its requested ID under failures. If every retrieval fails, the tool returns an actionable MCP error without comparison data.

  • get_big_deals(limit?) retrieves likely notable deal articles. The default limit is 10 and the maximum is 25.

  • find_bank_bonuses(bank?, state?, amount_min?) retrieves up to 10 likely bank-bonus source articles. bank is an institution text signal, state is a two-letter USPS state or District of Columbia code (case-insensitive), and amount_min is a positive whole-dollar threshold up to $1,000,000.

  • find_credit_card_offers(issuer?, card?, bonus_min?) retrieves up to 10 likely credit-card source articles. Issuer and card name are source-text signals; bonus_min is a positive integer up to 1,000,000 compared within each source-mentioned unit.

Post tools return source-backed fields under source: the stable ID, original URL, title, publication and modification timestamps, and cleaned article text. Interpretive fields live separately under derived. The server sets derived.outdatedWarning when the article has not been modified for more than 180 days. This conservative threshold uses the only dependable freshness signal available in the source contract—the modification timestamp— and avoids inferring an offer-specific expiration date from prose. It is a prompt to verify the source, not a claim that the offer is valid or expired.

Comment contracts and pagination

Both comment tools use Doctor of Credit's unauthenticated public WordPress comments endpoint and return fixed pages of at most 100 comments in ascending publication order. There is no configurable page size and no RSS fallback. Each comment has this source-backed shape:

{
  "source": {
    "id": 501,
    "postId": 123,
    "parentCommentId": null,
    "authorName": "Public Author",
    "publishedAt": "2026-08-20T14:30:00Z",
    "url": "https://www.doctorofcredit.com/example/#comment-501",
    "commentText": "Readable plain comment text"
  }
}

parentCommentId is null for a root comment and the positive parent comment ID for a reply. IDs, the public author name, UTC publication timestamp, permalink, and cleaned comment text all come from the public source. A successful tool result is { comments, pagination }; pagination contains page, fixed pageSize: 100, totalItems, totalPages, and hasNextPage. Text content is the JSON serialization of the same value returned as structured content. A valid empty first page returns comments: [], zero totals, and hasNextPage: false rather than an error.

Callers must keep requesting pages until hasNextPage is false. For example, this complete recent-comment scan keeps one fixed before cutoff on every page:

const after = "2026-08-01T00:00:00Z";
const before = "2026-08-08T00:00:00Z"; // Fix once for a repeatable scan.
let page = 1;
const comments = [];

while (true) {
  const result = await client.callTool({
    name: "get_recent_comments",
    arguments: { after, before, page },
  });
  if (result.isError) throw new Error(result.content[0].text);

  const current = result.structuredContent;
  comments.push(...current.comments);
  if (!current.pagination.hasNextPage) break;
  page += 1;
}

Keep the same after and before values for the entire loop; moving the before cutoff while paging can make the scan drift. Public WordPress data does not expose moderation approval time, so successive recent-comment scans should use overlapping time windows and deduplicate downstream by the stable source.id. Persistence, retries, page checkpoints, retrieval timestamps, deduplication, source-snapshot association, evidence classification, and scouting schedules also belong in downstream clients.

Comment retrieval is strictly read-only and requests only the public id, post, parent, author_name, date_gmt, content, and link fields. It sends no authentication, cookies, nonces, session data, or write request, and does not expose email addresses, IP addresses, avatars, moderation metadata, or other privileged commenter data. Any malformed comment or pagination value fails the entire page without partial structured content.

Comment-thread manifests

The optional doctor-of-credit/thread-manifest server capability advertises get_post_comment_manifest, manifest schema version 1, and comment normalization version doctor-of-credit-comments-v1. Clients that do not see that capability can continue using get_post_comments sequentially; the existing retrieval tools and their responses are unchanged.

get_post_comment_manifest reads every fixed-size comment page in order twice and returns { manifest } only when both complete observations agree, with this shape:

{
  "postId": "123",
  "schemaVersion": "1",
  "normalizationVersion": "doctor-of-credit-comments-v1",
  "observedAt": "2026-09-03T12:00:00.000Z",
  "pageSize": 100,
  "totalItems": 101,
  "totalPages": 2,
  "pages": [
    { "page": 1, "itemCount": 100, "digest": "<sha256>" },
    { "page": 2, "itemCount": 1, "digest": "<sha256>" }
  ]
}

Each lowercase SHA-256 digest hashes the JSON serialization of that page's ordered comments. Version 1 serializes objects with the fields upstreamId, parentCommentId, authorName, publishedAt, canonicalUrl, and content, in that order. IDs are decimal strings; a missing parent is null; author and content use Unicode NFKC plus trimming; timestamps use ISO UTC; URLs use the standard URL serialization; and CRLF in content is normalized to LF. The content value is the same cleaned public comment text returned by get_post_comments. Array order is significant.

The tool returns no comment bodies. It uses the same unauthenticated public GET request and restricted WordPress field list as comment retrieval, and is advertised as read-only and non-destructive. A malformed comment, missing or duplicate page membership, changing totals, invalid global order, or unsupported normalization version fails without partial manifest data. In that case, consumers should fall back to full sequential comment retrieval.

get_recent_posts falls back to the global or category-specific RSS feed when WordPress is unavailable or returns invalid data. RSS items use the same post shape, but RSS does not publish a modification timestamp, so modifiedAt is null for those results. Their outdated warning conservatively uses the publication timestamp instead. The server does not persist retrieved content or metadata.

search_posts uses WordPress search directly so relevance and all filters are applied by the source. It does not fall back to the recent-post RSS feed, because that feed cannot provide a complete or relevance-ranked search result.

get_big_deals applies a deterministic candidate policy to the 100 most recent posts (using the existing RSS fallback when WordPress is unavailable). An article qualifies when its cleaned title or text contains a dollar amount of at least $500 or an amount of at least 50,000 immediately followed by “points” or “miles.” Candidates are ordered by: number of qualifying signal types, largest dollar mention, largest points/miles mention, publication date, then stable post ID, all descending. The matched maxima and qualifying-signal count appear under derived.selectionSignals; they are text-selection signals, not assertions about an offer's value, availability, or validity. Every candidate otherwise retains the shared source and warning contract.

find_bank_bonuses searches up to 100 WordPress results using the supplied institution, the state's full name, and “bank bonus” as search terms. It then keeps only articles whose cleaned title/text contains both “bonus” and a banking term (bank, banking, checking, savings, credit union, or deposit account). Optional filters must also appear in the source text: the institution is matched case-insensitively, geography matches the full state name or uppercase postal code, and the largest dollar mention must meet amount_min. Results are ordered by publication date and stable ID, descending, then capped at 10. Match booleans and the largest dollar mention live under derived.bankBonusSignals; they identify candidate evidence only and do not assert geographic eligibility, direct-deposit requirements, availability, offer value, or current validity. Search failures return errors rather than falling back to an incomplete recent-post feed.

find_credit_card_offers searches up to 100 WordPress results using the supplied issuer, card name, and “credit card offer” as search terms. It keeps only articles whose cleaned title/text contains both a credit-card term and an offer signal (bonus, offer, welcome, or sign-up). Optional issuer and card filters must also occur in the source text. bonus_min matches when either the largest dollar mention or the largest points/miles mention meets the threshold in its own source unit; dollars and rewards are never converted or valued against one another. Results are ordered by publication date and stable ID, descending, then capped at 10. All match booleans and amount mentions live under derived.creditCardOfferSignals; they are candidate evidence only and do not assert eligibility, bonus value, restrictions, availability, or current validity. Search failures return errors rather than incomplete RSS results.

Upstream HTTP, network, and response-validation failures are returned as actionable MCP tool errors rather than empty or fabricated results.

Related MCP server: hidrix-tools

Development

npm run typecheck
npm test

Tests exercise behavior through an MCP client. Most use an in-memory MCP transport with controlled upstream HTTP fixtures; a smoke test launches the compiled stdio entry point.

Planned tools

I’d next add higher-level research tools: Those higher-level tools would search and collect likely articles, but let the connected model interpret restrictions, expiration dates, direct-deposit rules, and similar prose. Results should always include: Original article URL Publication and modification dates Cleaned article text An explicit distinction between source data and AI-derived fields Warnings when an offer may be outdated Internally, it can use the WordPress endpoint first, RSS as a fallback, and a small SQLite cache. No separate public REST service is necessary—the MCP server itself becomes the interface. A TypeScript implementation using the official MCP SDK would make a clean local server that works over stdio, with optional remote HTTP support later.

Available Tools

8 tools
compare_offersA

Retrieve up to 10 selected Doctor of Credit posts together without merging or inferring their offer terms.

ParametersJSON Schema
NameRequiredDescriptionDefault
post_idsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
postsYes
failuresYes

TDQS

A4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'without merging or inferring their offer terms', which is a key non-destructive behavioral trait. This adds value beyond the schema and clarifies what the tool does not do. However, it does not mention return format or potential errors, though an output schema exists, reducing that need.

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 a single, well-structured sentence of 13 words. It front-loads the verb 'Retrieve' and immediately follows with the key constraints ('up to 10', 'selected', 'without merging'). Every word earns its place with zero redundancy.

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?

For a tool with one parameter and an existing output schema, the description covers the core behavior and key constraints. It does not provide explicit usage guidance or parameter definitions, but the tool's simplicity and the presence of an output schema mitigate these gaps. The description is concise yet sufficient for a straightforward retrieval operation.

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 schema has 0% description coverage, so the description must compensate. It refers to 'selected Doctor of Credit posts', which reasonably maps to the `post_ids` parameter, but it does not explicitly state that post_ids are the IDs of the posts to retrieve. The description gives context but leaves the exact mapping implicit. Given the simplicity, a 3 is appropriate.

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's function: 'Retrieve up to 10 selected Doctor of Credit posts together'. The verb 'Retrieve' and specific resource ('selected Doctor of Credit posts') make the purpose explicit. The qualifier 'without merging or inferring their offer terms' further distinguishes it from any analysis or processing, setting it apart from sibling tools like search_posts or get_big_deals.

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

Usage Guidelines3/5

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

The description implies usage when a user needs to retrieve multiple specific posts at once, but it does not explicitly state when to use this tool over alternatives. There is no direct mention of sibling tools or exclusions, such as 'for a single post, use get_post'. The context is clear but not elaborated.

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

find_bank_bonusesA

Find up to 10 likely bank-bonus source articles using optional institution, USPS state, and minimum dollar-mention filters.

ParametersJSON Schema
NameRequiredDescriptionDefault
bankNo
stateNo
amount_minNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
postsYes

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses the result cap ('up to 10') and the heuristic nature ('likely'), which is useful, but it does not mention sorting behavior, error cases, or what happens with no filters. This is adequate but lacks depth.

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 a single, front-loaded sentence that efficiently communicates the tool's purpose, scope, and filters without any wasted words. Every element adds value.

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?

Given the presence of an output schema, return values need not be described. The description covers the core behavior (find bank-bonus articles with filters) and the key limit (up to 10). It omits trivial details like filter combination logic (AND/OR) and default ordering, but these are not critical for a simple search tool.

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?

With 0% schema_description_coverage, the description compensates by semantically mapping each parameter: bank→institution, state→USPS state, amount_min→minimum dollar-mention. This adds meaning beyond the bare property names, though it omits format constraints like state abbreviation style or amount units.

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 uses a specific verb 'Find' with a clear resource ('bank-bonus source articles') and scope ('up to 10 likely'), making its purpose immediately clear. It distinguishes itself from sibling tools like search_posts and find_credit_card_offers by focusing on bank-bonus articles with optional filters.

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

Usage Guidelines3/5

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

The usage context is implied: use this tool when you need to find bank-bonus articles with optional institution, state, or amount filters. However, it does not explicitly state when not to use it or name alternatives, leaving the guidance at an implied level.

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

find_credit_card_offersA

Find up to 10 likely credit-card offer source articles using optional issuer, card-name, and minimum source-unit bonus filters.

ParametersJSON Schema
NameRequiredDescriptionDefault
cardNo
issuerNo
bonus_minNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
postsYes

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds a concrete result limit ('up to 10') and the probabilistic nature ('likely') of the matches, which is useful. However, it does not disclose whether the operation is read-only (though 'Find' implies it), how results are ordered, what happens with no filters, or any error conditions. Given these gaps, the description is minimally transparent but not comprehensive.

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 a single, tight sentence that front-loads the main action and includes all relevant filter information. There is no verbose or redundant content; every phrase earns its place. It is efficiently structured for quick parsing.

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 tool is simple with three optional parameters and an existing output schema, so the description need not explain return values. It covers the primary behavior and the filter constraints, making it sufficient for basic invocation. However, it lacks explicit usage exclusions or alternative tool references, which would enhance completeness. Given the low complexity, the description is largely adequate.

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 0%, so the description must compensate for parameter meaning. It does rephrase each parameter into human-readable filter concepts: 'issuer', 'card-name', and 'minimum source-unit bonus' map to issuer, card, and bonus_min respectively. This adds meaning beyond the raw parameter names, but it does not specify formats, matching rules, or units beyond 'source-unit bonus'. The mapping is present but shallow.

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 specifies the tool's purpose: finding up to 10 credit-card offer source articles, with a specific verb ('Find') and resource ('credit-card offer source articles'). It differentiates from siblings like find_bank_bonuses by targeting credit-card offers, and its scope is distinct from generic search_posts. Though it doesn't explicitly name alternatives, the domain specificity makes its purpose unambiguous.

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

Usage Guidelines3/5

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

The description implies usage through its domain-specific phrasing and filter list, but it does not provide explicit guidance on when to use this tool versus alternatives like search_posts or compare_offers. There is no 'use this when...' or 'instead of...' guidance, so the agent must infer from the title and context. The optional filters are mentioned, but no exclusions or prerequisites are stated.

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

get_big_dealsA

Retrieve likely notable Doctor of Credit deal articles using documented amount-mention signals (default limit: 10; maximum: 25).

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
postsYes

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the full behavioral burden. It discloses the heuristic nature ('likely notable'), the use of 'documented amount-mention signals', and the default/max limits. However, it does not mention ordering, time scoping, authentication requirements, or explicitly state that this is a read-only operation, though 'Retrieve' implies non-mutating.

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 a single sentence of about 22 words that front-loads the main purpose ('Retrieve likely notable Doctor of Credit deal articles') before adding methodology and constraints. It is concise, contains no fluff, and every segment earns its place.

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?

For a tool with one optional parameter and an output schema, the description covers the essential what, how, and limits. The output schema reduces the need to explain return values, but the description lacks explicit usage guidance and details on result ordering or recency, which would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, 'limit', has its default, maximum, and exclusiveMinimum fully defined in the input schema. The description merely repeats 'default limit: 10; maximum: 25' without adding semantic context such as 'number of articles to return' or any behavior tied to the limit. With 0% schema description coverage, the description should compensate, but it adds no new meaning beyond the schema.

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 verb 'Retrieve' and the specific resource 'likely notable Doctor of Credit deal articles', adding the method 'using documented amount-mention signals'. This distinguishes it from sibling tools like get_recent_posts, search_posts, and get_post by focusing on notable deals with a special signal-based selection.

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

Usage Guidelines3/5

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

The description implies usage when notable deal articles are needed, but it does not explicitly mention when to use this tool versus alternatives or when not to use it. There is no exclusionary guidance or reference to sibling tools such as search_posts, so the context is implied rather than clearly stated.

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

get_postA

Retrieve a Doctor of Credit post by ID or URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
url_or_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
postYes

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description carries full burden. 'Retrieve' signals a non-destructive read operation, but no additional behavioral traits (e.g., error behavior, required permissions) are disclosed. It is a minimal but clear indication of read-only intent.

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?

Single sentence, grammatically correct, immediately front-loads the action and target. No superfluous words.

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?

Given the simple single-parameter design and the presence of an output schema, the description sufficiently covers the core behavior. However, it lacks any explicit guidance on usage context or edge cases, making it adequate but not outstanding.

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?

The schema offers no description for url_or_id, leaving the description to explain that an integer represents an ID and a string is a URL. This adds meaningful interpretation to the parameter's polymorphic nature.

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 uses the specific verb 'Retrieve' with resource 'Doctor of Credit post' and identifies the access method 'by ID or URL,' clearly distinguishing it from sibling tools like get_recent_posts or search_posts.

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

Usage Guidelines3/5

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

The description implies usage when the caller already has a post ID or URL, but it does not explicitly state when to prefer this tool over alternatives or mention any exclusions. No comparison to siblings is given.

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

get_recent_postsA

Retrieve recent Doctor of Credit posts, optionally filtered by category slug (default limit: 10; maximum: 100).

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
categoryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
postsYes

TDQS

A3.8/5.0
Behavior2/5

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

With no annotations, the description carries the full burden. It only repeats schema-visible constraints (default/max limit) and implies a read-only operation via 'Retrieve'. It does not disclose error behavior, pagination, ordering semantics, or any edge cases.

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?

One sentence with all key info front-loaded. No filler or redundancy.

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 tool is simple (2 optional params) and the description covers the essential invocation details. An output schema exists, so return values need not be described. Missing behavioral notes (e.g., ordering, auth) are minor given the straightforward read-only purpose.

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 gives semantic meaning to both parameters by naming 'category slug' and stating limit constraints, but this largely overlaps with the schema's pattern/default/max. Since schema description coverage is 0%, it adds some value but not enough to fully compensate.

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 action ('Retrieve recent Doctor of Credit posts') and specifies the optional category filter, making it distinct from sibling tools like get_post (single post) and search_posts (search-based).

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 provides clear context (recent posts, optional category slug) but does not explicitly mention when not to use it or compare to alternatives like search_posts. The guidance is inferred from the description rather than stated.

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

list_categoriesA

List the categories available from Doctor of Credit.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
categoriesYes

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description must convey behavioral transparency. The term 'list' implies a safe, read-only operation, but the description does not disclose details such as ordering, whether categories are dynamically fetched, or any limitations. For a zero-parameter list, this is adequate but minimal.

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 a single concise sentence, front-loaded with the verb and resource. Every word contributes to clarity with no redundancy or fluff.

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?

Given the tool's simplicity (zero parameters and an output schema already defined), the description provides enough context for an agent to invoke it correctly. It does not need to explain return values since the output schema exists, and the purpose is fully captured. Slightly more context about the nature of the categories could be added, but it is not essential.

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?

The tool has no parameters, so the description has no parameters to document. The baseline for zero parameters is 4, and the description correctly reflects that the operation takes no input, adding no unnecessary information.

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 action (list) and the resource (categories from Doctor of Credit). It distinguishes from sibling tools that handle posts, offers, and deals, making its purpose unambiguous.

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

Usage Guidelines3/5

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

The description implies use when the user needs to see available categories, but it does not explicitly state when to use this tool over alternatives. No exclusions or alternative pointers are provided, though the resource name makes the intended context obvious.

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

search_postsA

Search Doctor of Credit posts by text, optionally filtered by category slug and publication date (default limit: 10; maximum: 100).

ParametersJSON Schema
NameRequiredDescriptionDefault
afterNo
limitNo
queryYes
categoryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
postsYes

TDQS

A4.1/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It discloses the default limit (10) and maximum (100), and the presence of optional filters, which is helpful. However, it omits behavioral details such as sort order, whether the search covers title/body, or read-only status (though 'search' implies read-only). Some value is added, but gaps remain.

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 a single, sentence-length structure that front-loads the action and resource. Every clause adds value (search, filters, limits) with no waste. It is highly concise and well-structured.

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?

An output schema exists, so return values are covered. The description gives essential usage details (query, filters, limits) and is appropriate for a moderate-complexity search tool. It lacks some behavioral nuances like matching fields and ordering, but the presence of the output schema and the core information makes it reasonably complete. A small gap remains around search semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description provides meaningful natural-language mappings for all parameters: query→text, category→category slug, after→publication date, and limit→default/max. This fully compensates for the lack of schema descriptions and adds significant semantics.

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 uses a specific verb 'Search' with a clear resource 'Doctor of Credit posts' and defines scope via text search with optional filters. This distinguishes it from siblings like get_post (single post) and get_recent_posts (no text search). The purpose is immediately clear.

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

Usage Guidelines3/5

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

The description outlines what the tool does (text search, optional category/date filters) and implies its use case, but it does not explicitly state when to use this over siblings or provide exclusions. There is clear context but no explicit alternative guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 8 tool updatesv0.1.0
    • First observedcompare_offers
    • First observedfind_bank_bonuses
    • First observedfind_credit_card_offers
    • First observedget_big_deals
    • First observedget_post
    • First observedget_recent_posts
    • First observedlist_categories
    • First observedsearch_posts
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Scored across 8 tools

Disambiguation4/5

Each tool has a clearly defined role, from general content browsing (list_categories, get_post, get_recent_posts, search_posts) to specialized offer lookups (find_bank_bonuses, find_credit_card_offers). Minor overlap exists between compare_offers and get_post (batch vs single retrieval) and between find_* tools and search_posts, but descriptions are clear enough to guide selection.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (list_categories, get_post, search_posts, compare_offers, find_bank_bonuses, etc.). No camelCase or inconsistent verb styles are present, making the naming highly predictable.

Tool Count5/5

With 8 tools, the server is well-scoped for its purpose as a Doctor of Credit content interface. It covers essential browsing and searching actions without unnecessary bloat, fitting comfortably within the ideal 3-15 tool range.

Completeness5/5

The tool set provides comprehensive coverage for a read-only content API: listing categories, retrieving posts by ID/URL, browsing recent posts, searching, and specialized queries for bank bonuses, credit card offers, and big deals. There are no obvious gaps that would hinder an agent from accessing the available content.

Maintenance

ActivityMaintained
ResponsivenessResponsive

Resources

Related MCP Connectors

Related MCP Servers