How do I use rescuedogs-mcp-server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rescuedogs-mcp-server Find medium-sized dogs good for first-time owners" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

rescuedogs-mcp-server

by ssatama

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

rescuedogs-mcp-server

npm version License: MIT

Search by lifestyle

Search demo

Get detailed profiles

Detail demo

MCP server for discovering rescue dogs from European and UK organizations. Search, filter, and get detailed profiles of dogs available for adoption.

Connect

Remote (recommended)

No install. Add the endpoint as a custom connector or remote MCP server:

https://mcp.rescuedogs.me/mcp

It speaks MCP streamable HTTP, needs no authentication, and is read-only.

Local (npm, stdio)

npm install -g rescuedogs-mcp-server

Then add it to your client's MCP config. For Claude Desktop that is ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows:

{
  "mcpServers": {
    "rescuedogs": {
      "command": "npx",
      "args": ["-y", "rescuedogs-mcp-server"]
    }
  }
}

Related MCP server: Glama MCP Server Search

Available Tools

rescuedogs_search_dogs

Search for rescue dogs with comprehensive filtering.

"Find medium-sized dogs good for first-time owners"
"Show me golden retrievers available to adopt in the UK"
"Find low-energy dogs suitable for apartments"

Parameters:

query - Free-text search
breed - Filter by breed name
breed_group - Filter by breed group: Designer/Hybrid, Guardian, Herding, Hound, Mixed, Non-Sporting, Sporting, Terrier, Toy, Working
size - Tiny, Small, Medium, Large, XLarge
age_category - puppy, young, adult, senior
sex - male, female
energy_level - low, medium, high, very_high
experience_level - first_time_ok, some_experience, experienced_only
home_type - apartment_ok, house_preferred, house_required
adoptable_to_country - ISO country code (GB, IE, FR, DE)
organization_id - Restrict to one rescue (see rescuedogs_list_organizations)
good_with_kids, good_with_dogs, good_with_cats - boolean
limit (1-50, default 10), offset - pagination
include_images - Include dog photos (default: false, max 5 dogs)
image_preset - thumbnail (200x200) or medium (400x400)
response_format - markdown (default) or json

rescuedogs_get_dog_details

Get full details for a specific dog including AI-generated personality profile.

"Tell me about the dog with slug 'buddy-12345'"
"Show me details for Max"

Parameters:

slug - Dog's URL slug (required)
include_image - Include photo (default: true)
image_preset - thumbnail or medium (default)
response_format - markdown (default) or json

rescuedogs_list_breeds

Get available breeds with counts and statistics.

"What breeds are available?"
"Show me herding breeds with at least 10 dogs"

Parameters:

breed_group - Filter by breed group (see the list under rescuedogs_search_dogs)
min_count - Minimum dogs available
limit - Number of breeds to return (1-100, default 20)
response_format - markdown (default) or json

rescuedogs_get_statistics

Get overall platform statistics.

"How many rescue dogs are available?"
"Show me platform statistics"

Parameters:

response_format - markdown (default) or json

rescuedogs_get_filter_counts

Get available filter options with counts based on current filters.

"What filter options are available if I've selected Labrador breed?"
"Show me available sizes for dogs in Spain"

Parameters:

current_filters - Object with any of breed, size, age_category, sex, adoptable_to_country
response_format - markdown (default) or json

rescuedogs_list_organizations

List rescue organizations with their statistics.

"Which rescue organizations are in the UK?"
"Show me all organizations"

Parameters:

country - Filter by ISO country code
active_only - Only active organizations (default: true)
limit - Number to return (1-50, default 20)
response_format - markdown (default) or json

rescuedogs_match_preferences

Find dogs matching your lifestyle preferences.

"I live in an apartment, have moderate activity, and am a first-time dog owner"
"Find dogs for an active family with a house and garden"

Parameters:

living_situation - apartment, house_small_garden, house_large_garden, rural
activity_level - sedentary, moderate, active, very_active
experience - first_time, some, experienced
has_children, has_other_dogs, has_cats - boolean. Set to filter; omit to not filter on it at all
adoptable_to_country - ISO country code
limit - Number of matches (1-20, default 5)
include_images - Include dog photos (default: false)
response_format - markdown (default) or json

rescuedogs_get_adoption_guide

Get information about the rescue dog adoption process.

"How does rescue dog adoption work?"
"Tell me about transport for adopting to the UK"
"What fees should I expect?"

Parameters:

topic - overview, transport, fees, requirements, timeline
country - ISO code for country-specific info

Geographic Scope

Dogs are listed by European and UK rescue organizations. They are currently located in the UK, Germany, Serbia, Bulgaria, Bosnia, Turkey and Cyprus, and most rescues ship across the EU, EEA and UK.

US, Canadian and Australian rescues are not covered.

Use rescuedogs_list_organizations to see where each rescue ships, and rescuedogs_get_filter_counts for the live list of destination countries - coverage changes as organizations are added.

Country Codes

Use these codes for the adoptable_to_country parameter:

Code	Country
GB	United Kingdom (UK also accepted)
IE	Ireland
DE	Germany
FR	France
ES	Spain
IT	Italy
NL	Netherlands
BE	Belgium
AT	Austria
RO	Romania
GR	Greece
BG	Bulgaria
CY	Cyprus

Dogs can be adopted to countries where the rescue organization ships to. Use rescuedogs_list_organizations to see which countries each organization serves.

Data Source

All data comes from rescuedogs.me, which aggregates listings from independent rescue organizations. At the time of writing that is roughly 1,400 available dogs across 96 breeds from 11 organizations; call rescuedogs_get_statistics for current figures. About 99% of dogs carry an AI-generated personality profile.

The platform is powered by the open-source rescue-dog-aggregator project, which handles collection, breed standardization, AI personality extraction, and the public API.

How the data is gathered, and how to be removed

Listings are collected from the public adoption pages of each rescue organization. Nothing behind a login, paywall or robots.txt restriction is collected, and no personal data about adopters or staff is stored.

Every result links to the rescue's own adoption page. This project sends people to the rescues; it does not take applications, take payment, or stand between an adopter and an organization.

If you run one of these organizations and want your listings removed, changed, or credited differently, open an issue on rescue-dog-aggregator or contact the maintainer. Removal requests are honoured, and no justification is required.

Transports

Transport	Entrypoint	Used by
stdio	`dist/index.js` (`npm start`)	Local clients, the npm package, Smithery
Streamable HTTP	`dist/http.js` (`npm run start:http`)	The remote endpoint at `/mcp`

The HTTP transport is stateless: every request gets its own server instance, so there are no sessions to expire and it scales horizontally without shared state. SSE is not implemented - it is deprecated in the MCP SDK, and the current spec revision defines only stdio and streamable HTTP.

The public endpoint is rate limited per IP, 120 requests/minute and 3,000 requests/hour. /health is exempt.

Those ceilings are deliberately generous. Hosted MCP clients egress from small shared IP pools, so a per-IP bucket is shared by everyone behind that client; the limits exist to stop a scraper hammering the backend, not to ration normal use.

Run it locally:

npm run dev:http          # tsx, no build step
# or
npm run build && npm run start:http

Then point the MCP Inspector at http://localhost:3000/mcp with transport "Streamable HTTP".

Docker

The stdio image installs the published npm package:

docker build -t rescuedogs-mcp .
docker run -i rescuedogs-mcp

The remote endpoint builds from source:

docker build -f Dockerfile.http -t rescuedogs-mcp-http .
docker run -p 3000:3000 rescuedogs-mcp-http

Environment Variables

Variable	Description	Default
`RESCUEDOGS_API_URL`	Base URL for the rescuedogs API	`https://api.rescuedogs.me`
`RESCUEDOGS_IMAGE_URL`	Base URL for the image CDN	`https://images.rescuedogs.me`
`PORT`	Port for the HTTP transport	`3000`
`HOST`	Bind address for the HTTP transport	`0.0.0.0`
`OPENAI_APPS_CHALLENGE`	Token served at `/.well-known/openai-apps-challenge` for OpenAI domain verification	unset (route returns 404)

Architecture

src/
├── index.ts              # Entry point — stdio transport
├── http.ts               # Entry point — streamable HTTP transport
├── http-app.ts           # Express app: /mcp, /health, rate limiting
├── server.ts             # Shared MCP server factory used by both entrypoints
├── constants.ts          # Shared constants (API URLs, cache TTLs, rate limits)
├── types.ts              # TypeScript type definitions for API responses
├── schemas/
│   └── index.ts          # Zod input schemas for all tools
├── services/
│   ├── api-client.ts     # Axios-based API client with retry logic
│   ├── cache-service.ts  # In-memory cache with TTL support
│   ├── formatters.ts     # Markdown formatters for API responses
│   ├── image-service.ts  # Image fetching and CDN transform URLs
│   └── projection.ts     # Allowlisted public shapes for JSON responses
├── tools/
│   ├── index.ts          # Tool registration barrel with logging wrapper
│   ├── search-dogs.ts    # rescuedogs_search_dogs handler
│   ├── get-dog-details.ts
│   ├── list-breeds.ts
│   ├── get-statistics.ts
│   ├── get-filter-counts.ts
│   ├── list-organizations.ts
│   ├── match-preferences.ts
│   └── get-adoption-guide.ts
├── utils/
│   └── mappings.ts       # Value mappings (age, sex, country, preferences)
└── data/
    └── adoption-guides.ts # Static adoption guide content

Development

# Install dependencies
npm install

# Run tests
npm test

# Run tests with coverage
npm run test:coverage

# Contract tests against the live API (excluded from `npm test`)
npm run test:contract

# Type check src
npm run typecheck

# Type check tests as well
npm run typecheck:tests

# Lint
npm run lint

# Lint with auto-fix
npm run lint:fix

# Report unused exports, files and dependencies
npm run lint:dead

# Check markdown links and cross-file heading anchors
npm run lint:links

# Build
npm run build

# Development mode (tsx)
npm run dev

CI runs lint, typecheck, typecheck:tests, lint:dead, lint:links, test and build on every pull request. test:contract runs on a schedule instead, so an upstream API outage cannot block an unrelated PR.

Changelog

See CHANGELOG.md. The 2.0.0 release changes the shape of response_format: "json" output; markdown output is unaffected.

Contributing

See CONTRIBUTING.md. Issues and PRs welcome!

Privacy and Terms

License

MIT

Available Tools

8 tools

rescuedogs_get_adoption_guideA

Get information about the rescue dog adoption process including transport, fees, requirements, and timeline.

ParametersJSON Schema

Name	Required	Description	Default
`topic`	No	Specific adoption topic to get information about	overview
`country`	No	ISO country code for country-specific adoption info

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, so the description must fully disclose behavior. It only states 'Get information', implying a read-only action, but fails to mention any potential side effects, authentication needs, or rate limits. This is adequate for a non-destructive guide 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, well-structured sentence that concisely conveys the tool's purpose without unnecessary 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 simplicity of the tool (no output schema, 2 optional params), the description adequately covers its functionality. However, it doesn't indicate the response format (e.g., text, structured data), which could be helpful but is not critical.

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% (both parameters described). The description adds meaning by listing the topics ('transport, fees, requirements, timeline') that correspond to the topic enum values, enhancing understanding beyond the schema's basic descriptions.

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 ('Get information') and clearly identifies the resource ('rescue dog adoption process') along with explicit aspects (transport, fees, requirements, timeline). This distinctly separates it from sibling tools like rescuedogs_search_dogs or rescuedogs_get_dog_details.

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 the tool is for general adoption process inquiries but does not provide explicit guidance on when to use it versus siblings. No alternatives or exclusions are mentioned.

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

rescuedogs_get_dog_detailsA

Get full details for a specific rescue dog including AI-generated personality profile, requirements, and adoption info.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Dog's URL-friendly slug (e.g., 'buddy-12345')
`include_image`	No	Include dog photo in response
`image_preset`	No	Image size preset: 'thumbnail' (200x200) or 'medium' (400x400)	medium
`response_format`	No	Response format: 'markdown' for human-readable or 'json' for structured data	markdown

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 carries the burden. It mentions return content (AI-generated profile, requirements, adoption info) but does not disclose any side effects, authentication needs, or rate limits.

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?

Single sentence that is front-loaded with the main action. Efficient but could benefit from slightly more structure (e.g., listing what is included).

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?

No output schema, but the description adequately covers the main return fields (personality, requirements, adoption info) for a simple retrieval tool. Missing minor details like pagination or error handling.

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%, with each parameter already documented. The description adds no additional meaning or context 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 'Get', the resource 'full details for a specific rescue dog', and distinguishes it from sibling tools like search and list by focusing on a single dog via slug.

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?

Usage is implied from context; the description does not explicitly state when to use this tool versus siblings (e.g., search_dogs). No alternative or exclusion is mentioned.

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

rescuedogs_get_filter_countsA

Get available filter options with counts based on current filter context. Use this to show users valid filter choices that won't result in empty searches.

ParametersJSON Schema

Name	Required	Description	Default
`current_filters`	No	Current filter context to show remaining options
`response_format`	No	Response format: 'markdown' for human-readable or 'json' for structured data	markdown

TDQS

A3.7/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It describes the tool as providing counts based on context, but omits crucial details: whether the operation is read-only, if it requires authentication, any rate limits, or what happens when filters produce no results. The lack of transparency could lead to incorrect assumptions.

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 two sentences with no filler. The key action and purpose are front-loaded, achieving maximum informational density.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of a response_format parameter, the description covers the basic purpose and usage. However, it lacks details on the returned data structure (e.g., which counts are provided) and does not compensate for the missing output schema. The complexity is low, so a score of 3 is 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 100%, so baseline is 3. The description adds minimal meaning beyond the schema—'based on current filter context' echoes the schema's parameter description. It does not elaborate on the structure of returned counts or how to interpret the response_format parameter.

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 specifies the verb 'Get', the resource 'available filter options with counts', and the context 'based on current filter context'. It clearly distinguishes from sibling tools like 'search_dogs' by focusing on filter enumeration rather than direct search results.

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?

The description directly advises 'Use this to show users valid filter choices that won't result in empty searches'. This provides clear usage context, though it does not explicitly contrast with alternative tools or state when not to use it.

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

rescuedogs_get_statisticsB

Get overall statistics about available rescue dogs on the platform.

ParametersJSON Schema

Name	Required	Description	Default
`response_format`	No	Response format: 'markdown' for human-readable or 'json' for structured data	markdown

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It only states 'Get overall statistics' without specifying read-only nature, authentication needs, or data granularity (e.g., counts, breakdowns).

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 concise sentence of 9 words, starting with the verb 'Get'. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite low complexity, the description omits what the statistics include (e.g., counts, averages, distributions) and there is no output schema. The agent may lack understanding of the returned data.

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 coverage is 100% for the single parameter 'response_format', which is fully defined in the schema. The description adds no extra meaning, but the baseline is 3 due to high schema coverage.

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 'Get' and resource 'overall statistics about available rescue dogs', distinguishing it from sibling tools like search, details, and breeds.

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?

No guidance on when to use this tool versus alternatives such as rescuedogs_get_filter_counts or rescuedogs_search_dogs. The description does not indicate prerequisites or context.

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

rescuedogs_list_breedsB

Get available breeds with counts and statistics. Shows which breeds have dogs available for adoption.

ParametersJSON Schema

Name	Required	Description	Default
`breed_group`	No	Filter by FCI breed group (e.g., 'Herding', 'Sporting')
`min_count`	No	Minimum number of dogs available for a breed to be included
`limit`	No	Number of breeds to return
`response_format`	No	Response format: 'markdown' for human-readable or 'json' for structured data	markdown

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It only states the tool returns counts and statistics, but lacks information on whether it's a read-only operation, any authentication requirements, or potential side effects.

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 two concise sentences that clearly state the tool's purpose and what it provides. No unnecessary words, and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite moderate complexity (four optional parameters, no output schema), the description omits important details such as the actual structure of the response, which would be critical for an agent using this tool without a separate output schema.

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?

All four parameters are described in the input schema (100% coverage), so the description adds no extra meaning beyond what the schema already provides. Baseline score of 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 verb 'get' and the resource 'available breeds with counts and statistics', making the purpose unambiguous. It also distinguishes from sibling tools like search_dogs or get_dog_details.

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?

No guidance is provided on when to use this tool vs alternatives. For example, it doesn't indicate that this is a pre-search step for browsing breeds, nor does it mention when to use rescuedogs_search_dogs instead.

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

rescuedogs_list_organizationsB

List rescue organizations with their statistics and available dogs count.

ParametersJSON Schema

Name	Required	Description	Default
`country`	No	Filter by ISO country code (e.g., 'GB', 'ES', 'RO')
`active_only`	No	Only return active organizations
`limit`	No	Number of organizations to return
`response_format`	No	Response format: 'markdown' for human-readable or 'json' for structured data	markdown

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are present, so the description carries full transparency burden. It only states the tool lists organizations with stats, but fails to disclose behavioral traits such as authentication requirements, rate limits, data freshness, pagination behavior, or the fact that output format depends on the response_format parameter. This leaves the agent underinformed.

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 9-word sentence. It is front-loaded and contains no extraneous information. Every word serves a purpose, making it highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters, no output schema, and no annotations, the description is incomplete. It does not mention output format options (though schema has response_format), pagination via limit, or the optional nature of country. Also lacks guidance on how this tool fits with sibling 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?

Baseline is 3 because schema description coverage is 100%. The description adds no additional meaning or context to the parameters beyond what the schema already provides. For instance, it does not explain how 'country' or 'active_only' filter results in practice.

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'), the resource ('rescue organizations'), and the output scope ('statistics and available dogs count'). It distinguishes itself from sibling tools like rescuedogs_search_dogs or rescuedogs_get_statistics by focusing on organizations.

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?

No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention scenarios where it's not appropriate. For example, it could note that this tool is for browsing organizations, while rescuedogs_get_statistics provides aggregated stats.

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

rescuedogs_match_preferencesA

Find dogs that match your lifestyle preferences. Translates your living situation, activity level, and experience into appropriate filters.

ParametersJSON Schema

Name	Required	Description	Default
`living_situation`	Yes	Your living situation for home type matching
`activity_level`	Yes	Your activity level for energy matching
`experience`	Yes	Your dog ownership experience level
`has_children`	No	Set to true to filter for dogs good with children, false to exclude them, or omit to not filter by this
`has_other_dogs`	No	Set to true to filter for dogs good with other dogs, false to exclude them, or omit to not filter by this
`has_cats`	No	Set to true to filter for dogs good with cats, false to exclude them, or omit to not filter by this
`adoptable_to_country`	No	ISO country code where you can adopt (e.g., 'GB', 'IE')
`limit`	No	Number of matching dogs to return
`include_images`	No	Include dog photos in response. Images returned for up to 5 dogs.
`response_format`	No	Response format: 'markdown' for human-readable or 'json' for structured data	markdown

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states it 'translates preferences into filters' without disclosing specific behaviors like pagination, output limits (image limit of 5 dogs is in param but not description), or side effects. Minimal transparency.

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 sentences, front-loaded with purpose, no wasted words. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 10 parameters and no output schema, the description is too brief. It lacks explanation of the transformation mechanism, response format, and limitations, leaving gaps for an agent.

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?

With 100% schema description coverage, baseline is 3. The description adds a brief summary of transformation but no new meaning beyond schema descriptions.

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 ('Find dogs') and the resource ('that match your lifestyle preferences'), with a specific verb and resource. It distinguishes from siblings like 'rescuedogs_search_dogs' by emphasizing preference-based matching.

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?

The description implies use when matching lifestyle preferences but does not explicitly exclude alternative tools or provide when-not scenarios. It is clear but lacks comparative guidance.

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

rescuedogs_search_dogsA

Search for rescue dogs available for adoption from European and UK organizations. Returns matching dogs with basic info. Use rescuedogs_get_dog_details for full profiles.

ParametersJSON Schema

Name	Required	Description	Default
`query`	No	Free-text search in dog names and descriptions
`breed`	No	Filter by breed name (e.g., 'Golden Retriever', 'Mixed')
`breed_group`	No	Filter by FCI breed group (e.g., 'Herding', 'Sporting', 'Hound')
`size`	No	Filter by standardized size
`age_category`	No	Filter by age category: puppy (0-12 months), young (1-3 years), adult (3-8 years), senior (8+ years)
`sex`	No	Filter by sex
`energy_level`	No	Filter by energy level from LLM profiler data
`experience_level`	No	Filter by required owner experience level
`home_type`	No	Filter by required home type
`adoptable_to_country`	No	ISO country code where dog can be adopted to (e.g., 'GB', 'IE', 'FR')
`organization_id`	No	Filter by specific rescue organization ID
`good_with_kids`	No	Set to true to filter for dogs good with children
`good_with_dogs`	No	Set to true to filter for dogs good with other dogs
`good_with_cats`	No	Set to true to filter for dogs good with cats
`limit`	No	Number of results to return (1-50)
`offset`	No	Number of results to skip for pagination
`include_images`	No	Include dog photos in response (opt-in, increases response size). Images returned for up to 5 dogs.
`image_preset`	No	Image size preset: 'thumbnail' (200x200) or 'medium' (400x400)	thumbnail
`response_format`	No	Response format: 'markdown' for human-readable or 'json' for structured data	markdown

TDQS

A3.9/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 traits. It states it returns 'matching dogs with basic info', but does not detail what 'basic info' includes, pagination behavior, or any rate limits. For a read-only search tool, it minimally conveys safety, but could be more explicit about response structure.

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 two sentences, front-loaded with the main purpose, and includes a clear pointer to a sibling tool. No unnecessary words, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 19 parameters, no output schema, and no behavioral annotations. The description is very brief, not summarizing the rich filtering capabilities or default behavior (e.g., limit=10, offset=0). It gives a high-level overview but lacks detail for an agent to fully understand the tool's scope without inspecting the schema.

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 coverage is 100% (all 19 parameters have descriptions). The description adds minimal extra semantic value beyond the schema, only summarizing the tool's purpose. Per guidelines, with high coverage, baseline is 3; description does not elevate beyond that.

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 'Search for rescue dogs available for adoption from European and UK organizations', specifying the verb (search), resource (rescue dogs), and geographic scope. It distinguishes from the sibling tool rescuedogs_get_dog_details by noting this returns basic info, while that provides full profiles.

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?

The description includes explicit guidance to use rescuedogs_get_dog_details for full profiles, indicating when this tool is appropriate vs. an alternative. However, it does not specify when not to use this tool relative to other siblings like rescuedogs_list_breeds or rescuedogs_get_filter_counts.

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.

8 tool updatesv1.2.0Jun 9, 2026
- First observedrescuedogs_get_adoption_guide
- First observedrescuedogs_get_dog_details
- First observedrescuedogs_get_filter_counts
- First observedrescuedogs_get_statistics
- First observedrescuedogs_list_breeds
- First observedrescuedogs_list_organizations
- First observedrescuedogs_match_preferences
- First observedrescuedogs_search_dogs

Deploy Server

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

TDQS

A3.9/5.0

Scored 2026-06-09 17:40 across 8 tools

Disambiguation5/5

Each tool targets a distinct aspect of rescue dog data: search, details, filters, statistics, breeds, organizations, preferences matching, and adoption guide. No overlapping purposes.

Naming Consistency5/5

All tools follow the consistent pattern 'rescuedogs_[verb]_[noun]' using snake_case, e.g., rescuedogs_search_dogs, rescuedogs_get_dog_details.

Tool Count5/5

8 tools are well-scoped for a rescue dog adoption platform, covering search, discovery, and informational needs without being too many or too few.

Completeness5/5

The tool surface covers the full user journey: search, filter, view details, match preferences, explore breeds and organizations, and access adoption guidance. No significant gaps.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

nü people Job Server A
io.github.nu-people
Public MCP server for discovering open jobs. Search, filter, and get application links.
Search
52
MCP Toplist A
com.mcptoplist
Search 77,000+ MCP servers ranked by real adoption data to find the right one for any task.
Search Developer Tools
23
MCP Finder B
io.github.c5huracan
Find the right MCP server for your task. 4,500+ servers ranked by community trust.
Search Developer Tools
3
Find MCP - Agentage MCP Directory A
io.agentage
Search the official MCP registry: 17,000+ servers with trust grades, stars, tools, install config.
Search Developer Tools Documentation Access
32

Related MCP Servers

mcp-registry-server
Search RAG Systems
KBB99
A
license
C
quality
D
maintenance
Easily find MCP servers using our MCP registry. Search with natural language.
Updated 2 years ago (2025-02-05 23:18 UTC)
1
5
MIT
Glama MCP Server Search
Search Developer Tools
kongyo2
A
license
A
quality
D
maintenance
An MCP server for searching and exploring MCP servers from the Glama MCP directory. This server provides tools to search for MCP servers, get detailed information about specific servers, and explore available server attributes using the Glama MCP API.
Updated a year ago (2025-08-11 12:07 UTC)
3
3
MIT
Board and Stable MCP Server
Databases Search
kevindarstNBB
A
license
Not graded
quality
D
maintenance
Search the fastest-growing US horse boarding directory: 6,000 facilities and 3,800 trainers across 48 states, plus boarding price data by state.
Updated 6 months ago (2026-03-31 21:52 UTC)
42 npm
MIT
MCP Discord
Communication Social Media App Automation
goul4rt
A
license
Not graded
quality
C
maintenance
The most complete open-source MCP server for Discord — 80+ tools, dual-mode: integrated (plugin) or standalone
Updated 3 months ago (2026-06-04 17:53 UTC)
11 npm
11
MIT