Which integrations are available for this server?

Enables discovery of businesses via Google Places Text Search API. Enables mobile performance measurements (LCP, INP, CLS) via PageSpeed Insights API. Provides local SQLite database for storing profiles, audits, history, and outcomes.

How do I use Agency Opportunity Radar?

1. Click on "Install 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., "@Agency Opportunity Radar Find fintech websites in Argentina that need agency services." 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.

Agency Opportunity Radar

by AlanFNL

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Agency Opportunity Radar

MCP server that finds evidence-backed opportunities for digital agencies.

Agency Opportunity Radar helps an AI research public business websites, identify observable website or SEO problems, match them to an agency's declared services, and explain every score with measurements, URLs, and timestamps.

It is a research tool, not an outreach tool. It does not discover personal contact details, submit forms, send messages, or provide a standalone dashboard. The MCP client—ChatGPT, Claude, Codex, or another compatible client—remains the interface.

What the interaction looks like

Ask the connected AI:

Find fintech websites in Argentina that our agency could optimize.

The AI can first discover explicit URLs or public Google Places results, request a bounded audit for promising candidates, and then compare the saved results. A synthetic result might be summarized like this:

Río Ledger shows one directly observed technical SEO issue:

- Missing meta description (severity 3/5, confidence 0.99)
  Evidence: no non-empty meta description was found on
  https://rio-ledger.example/ at 2026-07-27T14:01:58Z.

Overall opportunity score: 73.5/100
- Need: 60
- Agency fit: 90
- Doability: 80
- Likely impact: 60
- Confidence: 80

Limitation: only one page was inspected. No traffic, revenue, budget, or
willingness-to-buy claim was made.

The complete structured example is in examples/example-audit-response.json.

Related MCP server: SEO Analyzer API

Why this is not a lead database

A lead database answers “who might I contact?” This server focuses on a different chain of reasoning:

Need — Is there an observable problem?
Fit — Does it map to a service the agency actually offers?
Doability — Is the likely work compatible with declared capabilities and exclusions?
Evidence — Which public observation supports each finding?

The server returns those inputs and deterministic score contributions. The connected AI interprets them and keeps uncertainty visible.

Requirements

Node.js 22.19 or newer
An MCP-compatible client
No API key for manual discovery and static website audits
Optional Google Places API key for query/location discovery
Optional PageSpeed Insights API key for mobile lab measurements

Install and build

From this repository:

npm install
npm run check

The compiled stdio server is dist/server.js. To run it directly:

node dist/server.js

The process speaks MCP over stdio, so it normally appears idle when started in a terminal. Configure it in an MCP client instead of typing into it.

MCP client configuration

Use absolute paths for the server, database, and export directory:

{
  "mcpServers": {
    "agency-opportunity-radar": {
      "command": "node",
      "args": [
        "/absolute/path/to/agency-opportunity-radar/dist/server.js"
      ],
      "env": {
        "RADAR_DATABASE_PATH": "/absolute/path/to/radar-data/opportunities.db",
        "RADAR_EXPORT_ROOT": "/absolute/path/to/radar-data/exports"
      }
    }
  }
}

A copyable version is available at examples/mcp-config.json.

Optional environment variables

Variable	Default	Purpose
`RADAR_DATABASE_PATH`	`./agency-opportunity-radar.db`	Local SQLite database
`RADAR_EXPORT_ROOT`	`./exports`	Only directory to which exports may be written
`GOOGLE_PLACES_API_KEY`	unset	Enables Google Places Text Search discovery
`PAGESPEED_API_KEY`	unset	Enables mobile PageSpeed measurements
`RADAR_REQUEST_TIMEOUT_MS`	`10000`	Per-request timeout
`RADAR_MAX_RESPONSE_BYTES`	`2000000`	Maximum response body read
`RADAR_MAX_REDIRECTS`	`5`	Redirect limit
`RADAR_REQUESTS_PER_MINUTE`	`12`	Per-domain request limit
`RADAR_CACHE_TTL_SECONDS`	`86400`	Provider and audit freshness window
`RADAR_VERBOSE`	`0`	Structured operational logs on stderr
`RADAR_ALLOW_PRIVATE_NETWORK`	`0`	Permit intentional local-site audits

Keep RADAR_ALLOW_PRIVATE_NETWORK=0 for ordinary use. Enabling it disables the private-network SSRF boundary and is intended only for trusted local fixtures or development sites.

First workflow

Configure the agency with agency_profile_set. The example at examples/agency-profile.json includes technical SEO, performance, and conversion services.
Ask the AI to call opportunity_discover with provider: "manual" and a list of public websites.
Call opportunity_audit for a returned candidateId.
Compare two or more saved reports with opportunity_compare.
Record a human decision with opportunity_record_outcome.
Retrieve it in a later conversation with opportunity_search_history.
Export selected snapshots with opportunity_export.

Manual discovery is intentionally useful without paid APIs:

{
  "query": "fintech websites in Argentina",
  "location": "Argentina",
  "provider": "manual",
  "websites": [
    "https://public-business.example/"
  ],
  "limit": 10
}

MCP tools

Tool	Bounded job
`agency_profile_set`	Create or replace the local agency profile
`agency_profile_get`	Inspect the active profile before research
`opportunity_discover`	Normalize manual URLs or optional Places results
`opportunity_audit`	Crawl and inspect one candidate with strict limits
`opportunity_compare`	Return a compact comparison of saved snapshots
`opportunity_search_history`	Filter searches, audits, and outcomes
`opportunity_record_outcome`	Append a human-reported business outcome
`opportunity_export`	Write selected results as JSON or CSV inside the configured root

Supported checks

The static detector pack currently covers:

missing page titles, meta descriptions, and canonical URLs;
accidental noindex directives;
missing or multiple primary headings;
missing mobile viewport declarations;
multiple parser-blocking scripts;
large declared images that load eagerly;
missing static primary actions;
forms without a visible privacy link;
HTTPS pages posting forms to HTTP;
public placeholder content;
stale copyright years as low-confidence supporting evidence;
crawled internal destinations returning HTTP errors;
mobile LCP, INP, and CLS when PageSpeed is configured.

Every signal refers to one or more evidence IDs. Evidence stores the minimum necessary observation rather than full page bodies. Audit responses also include pages inspected, failed checks, next investigations, limitations, and the exact scoring configuration.

Scoring

All dimensions use a 0–100 scale. The initial, inspectable formula is:

overall =
  30% need
  25% agency fit
  20% doability
  15% likely impact
  10% confidence

This is a deterministic starting point, not an objective truth. Each audit stores its scoring version, weights, dimension values, contributing signal IDs, and plain-language reasons. A refresh creates a new snapshot instead of rewriting the old result.

Confidence falls when pages or providers fail, no inspectable page is available, or only one page is inspected. Likely impact is relative and directional; the server does not invent revenue or conversion-loss estimates.

Network and data safety

Only HTTP and HTTPS targets are accepted.
Credentials in URLs are rejected.
Loopback, private, link-local, carrier-grade NAT, multicast, reserved, and metadata-service addresses are blocked by default.
DNS is checked and pinned for each request, and every redirect is checked again.
Crawls respect robots.txt and enforce page, redirect, response-size, timeout, concurrency, and per-domain request bounds.
Login, logout, cart, checkout, and admin crawl paths are skipped.
Query tokens and common credential parameters are redacted from stored URLs.
API keys come from environment variables and are never written to results or operational logs.
Full HTML bodies are not stored.
Forms are never submitted.
CSV exports neutralize spreadsheet-formula prefixes and never overwrite files.
Exports cannot escape RADAR_EXPORT_ROOT.
The MVP collects no personal email addresses or phone numbers and performs no outreach.

Current limitations

Google Places is optional, quota-controlled, and may omit website fields.
Static HTML checks cannot prove that a visually rendered interaction works.
JavaScript-rendered content may be absent from the static response.
PageSpeed availability depends on API access and external service behavior.
The crawler inspects only a bounded subset of public pages.
It does not bypass authentication, CAPTCHAs, paywalls, or access controls.
It has no backlink index, paid-ad intelligence, social analysis, contact enrichment, CRM automation, or standalone UI.
deep increases the bounded page sample; it does not perform the Phase 4 destructive or form-submission interactions excluded by the build plan.

Failed checks remain in the report and reduce confidence rather than disappearing.

Local storage

SQLite tables keep agency-profile snapshots, services, searches, candidates, audits, evidence, signals, scoring snapshots, outcomes, and provider cache entries. This gives a later AI conversation canonical history even when chat history is summarized or unavailable.

The server does not train an opaque ranking model from outcomes. Recorded outcomes are returned as transparent context.

Development and tests

npm run typecheck
npm test
npm run build

npm run check runs all three.

The deterministic test suite includes:

URL normalization, secret redaction, and private-address boundaries;
redirect, timeout, and response-size handling;
ten local website fixtures spanning healthy, broken, ambiguous, and blocked behavior;
evidence-to-signal referential integrity;
score calculation and confidence penalties;
SQLite migrations, immutable snapshots, restart durability, and outcomes;
Places caching and partial PageSpeed failures;
export confinement and overwrite protection;
MCP tool discovery and end-to-end invocation over an in-memory transport.

Network-dependent live evaluations are intentionally separate. See test/evaluation/README.md for the human-review requirements before a public site becomes evaluation ground truth.

Project boundaries

This MVP is for evidence-led research. It is not a spam system, contact-enrichment service, automatic proposal generator, or substitute for human review. Use public and authorized data, respect site policies, and verify consequential conclusions before acting.

License

MIT

Available Tools

8 tools

agency_profile_getGet agency profileA

Read-onlyIdempotent

Returns the current local agency profile so assumptions can be checked before research.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare the tool as read-only and idempotent. The description adds minimal context about being 'local' and for 'checking assumptions,' which is useful but does not significantly expand beyond what the annotations provide.

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, 13 words, with no wasted words. It front-loads the action ('Returns') and purpose.

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

Completeness5/5

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

For a tool with no parameters and an existing output schema, the description sufficiently communicates purpose and behavior. It is complete for the intended use.

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?

There are no parameters, so schema coverage is 100%. The description adds no parameter information, but the baseline score of 3 applies.

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 returns the current local agency profile, with a specific use case (checking assumptions before research). The name and title align, and it is distinguishable from sibling tools like agency_profile_set.

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 usage before research to verify assumptions, providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives among siblings.

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

agency_profile_setSet agency profileB

Destructive

Creates or replaces the local agency profile used for fit and doability scoring.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`notes`	No
`services`	Yes
`targetMarkets`	No
`targetLocations`	No
`preferredCompanySizes`	No
`minimumOpportunityScore`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that it 'creates or replaces', which aligns with destructive. However, it does not disclose additional behavioral traits such as irreversible changes, required permissions, or performance impact.

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?

The description is a single sentence with no wasted words, achieving conciseness. However, it lacks structure such as bullet points or sections; a slightly more structured format could improve scannability without adding length.

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 7 parameters (including complex nested services), no parameter descriptions, and a minimal description, the contextual completeness is low. The agent lacks guidance on what each field means or how to use the tool effectively.

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

Parameters1/5

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

The schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The description provides no explanation of parameters (name, services, notes, targetMarkets, etc.). The agent receives no semantic guidance beyond the schema's type constraints.

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 'creates or replaces' and the resource 'local agency profile', with a specific purpose 'used for fit and doability scoring'. This distinguishes it from sibling tools like agency_profile_get (retrieval) and opportunity_* tools.

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 for setting the agency profile but does not explicitly state when to use this tool versus alternatives (e.g., agency_profile_get) or when not to use it. No usage context, prerequisites, or side effects are mentioned.

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

opportunity_auditAudit a public website opportunityB

Runs a bounded, robots-aware public website audit and returns observations, evidence-linked signals, explicit failures, and deterministic score reasons. It never submits forms.

ParametersJSON Schema

Name	Required	Default
`url`	No
`depth`	No	standard
`refresh`	No
`maxPages`	No
`serviceIds`	No
`candidateId`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior4/5

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

The description discloses key behaviors: the audit is bounded and robots-aware, returns detailed results, and never submits forms. This adds value beyond annotations (which don't mention these specifics). However, it could further detail what 'bounded' means (e.g., limits on pages or 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?

Two sentences, no wasted words. The 'never submits forms' adds a key safety note efficiently. Front-loaded with the main action and return types.

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 an output schema existing, the description lacks essential input parameter details and does not clarify scope ('bounded') or prerequisites. For a tool with 6 parameters and no schema descriptions, more completeness is needed.

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

Parameters1/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 by explaining parameter purposes. It fails to mention any of the 6 parameters (url, depth, refresh, maxPages, serviceIds, candidateId), leaving the agent without guidance on how to invoke the tool.

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

Purpose4/5

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

The description clearly states it runs a bounded, robots-aware public website audit and lists specific return types (observations, signals, failures, score reasons). The verb 'audit' and resource 'public website opportunity' are specific, but it does not explicitly differentiate from sibling tools like opportunity_discover.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or context such as needing an existing opportunity ID.

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

opportunity_compareCompare audited opportunitiesC

Read-onlyIdempotent

Returns a compact, consistently shaped comparison of saved audit snapshots without generating sales copy.

ParametersJSON Schema

Name	Required	Description	Default
`serviceIds`	No
`opportunityIds`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, idempotent operation. The description adds that the comparison is 'compact' and 'consistently shaped' and that it does not generate sales copy, but this is minimal additional behavioral context.

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, clear, and concise sentence with no unnecessary words. It front-loads the core purpose and is appropriately sized.

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?

Although an output schema exists, the description fails to explain the input parameters, which have no descriptions in the schema. With sibling tools that have similar inputs, more context is needed to ensure correct invocation.

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

Parameters1/5

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

Schema description coverage is 0%, meaning no parameter descriptions in the schema. The description does not mention any parameters or explain what opportunityIds or serviceIds represent. This is a critical gap for effective tool use.

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

Purpose4/5

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

The description clearly states the tool returns a comparison of saved audit snapshots, with a specific verb 'returns' and resource 'saved audit snapshots'. It does not explicitly differentiate from siblings like opportunity_discover or opportunity_audit, but the operation is distinct enough to be understood.

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?

The description provides no guidance on when to use this tool versus alternatives like opportunity_discover or opportunity_audit. No exclusions or context for use are mentioned.

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

opportunity_discoverDiscover opportunity candidatesA

Finds and normalizes public business websites using explicit URLs or the optional Google Places provider. It does not deeply audit them.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	Yes
`location`	No
`provider`	No	manual
`websites`	No
`serviceIds`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

The description adds value beyond annotations by mentioning normalization and the Google Places provider. It also states the tool does not deeply audit. No contradiction with annotations. However, it does not clarify whether the tool creates records (given readOnlyHint=false), which would be useful.

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 20-word sentence that immediately conveys the core action and constraints. No wasted words; front-loaded with the main verb and resource.

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 high parameter count and lack of schema descriptions, the description is too brief. It does not explain the purpose among siblings beyond the audit comment, nor does it cover parameter usage or result behavior. The output schema exists but does not compensate for missing parameter context.

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?

With 0% schema description coverage, the description only explains 'websites' (explicit URLs) and 'provider' (Google Places), leaving 'query', 'location', 'limit', and 'serviceIds' undocumented. This is insufficient for a 6-parameter tool, even considering the output 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 it 'finds and normalizes public business websites', specifying the verb and resource. It distinguishes from sibling 'opportunity_audit' by explicitly noting it does not deeply audit, making the purpose well-defined.

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 for discovering candidates via URLs or Google Places, but does not provide explicit guidance on when to use versus alternatives or when not to use it. The 'not deeply audit' hint is helpful but insufficient for clear usage criteria.

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

opportunity_exportExport opportunitiesA

Writes selected saved opportunities as JSON or CSV inside the configured export directory. Existing files are never overwritten.

ParametersJSON Schema

Name	Required	Description	Default
`format`	Yes
`filename`	No
`opportunityIds`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Discloses that files are never overwritten, which is a key safety trait, but does not explain behavior when a file already exists, permissions needed, or return value (though output schema exists).

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 the primary action, no redundant text.

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?

With 3 parameters, no annotations, and an output schema, the description covers core purpose and a key constraint (no overwrite) but omits details on error handling, file naming conflicts, and required permissions.

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?

Schema description coverage is 0%; the description adds minimal context (JSON/CSV format, export directory) but does not describe individual parameters like opportunityIds or filename 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 clearly states the tool writes selected opportunities as JSON or CSV to a configured directory, distinguishing it from sibling tools like discovery, audit, and comparison.

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?

No explicit guidance on when or when not to use the tool versus alternatives; usage is implied by the tool name and purpose but not elaborated.

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

opportunity_record_outcomeRecord opportunity outcomeA

Appends a human-reported outcome to an audited opportunity. It does not contact the business or change any external system.

ParametersJSON Schema

Name	Required	Description	Default
`notes`	No
`value`	No
`status`	Yes
`reasons`	No
`currency`	No
`opportunityId`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds clarity by confirming no external system changes, enhancing transparency beyond annotations.

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 purpose and followed by side-effect clarification. Every word adds value.

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 6 parameters and the presence of an output schema, the description covers the overall operation but lacks parameter-level details needed for correct invocation.

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?

With 0% schema description coverage, the description should explain parameter meanings. It only provides high-level context without detailing required fields like status or optional ones like value and currency.

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 appends a human-reported outcome to an audited opportunity, using a specific verb and resource. This distinguishes it from sibling tools like opportunity_discover or opportunity_audit.

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 when to use (recording a manual outcome) and states it does not contact external systems, but does not explicitly list alternatives or when-not-to-use cases.

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

opportunity_search_historySearch opportunity historyC

Read-onlyIdempotent

Retrieves persisted searches, audit snapshots, and outcomes using transparent filters.

ParametersJSON Schema

Name	Required	Description	Default
`to`	No
`from`	No
`limit`	No
`query`	No
`status`	No
`provider`	No
`serviceId`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that it retrieves historical data with transparent filters, providing some context but not going beyond annotations.

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?

The description is concise at one sentence but lacks structure. It front-loads the verb 'Retrieves' effectively, but could be improved with more detail on parameters.

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?

With 7 parameters and no schema descriptions, the description is too brief. It does not cover key aspects like time range filtering or status options, leaving significant gaps for such a complex tool.

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

Parameters1/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. However, it only mentions 'transparent filters' without explaining any of the 7 parameters, adding no semantic value.

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

Purpose4/5

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

The description clearly states the tool retrieves persisted searches, audit snapshots, and outcomes using transparent filters. It specifies the action and resources but does not explicitly distinguish it from sibling tools.

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. The description lacks any context about appropriate use cases or 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.

Tool Schema Changelog

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

8 tool updatesv0.1.0Jul 28, 2026
- First observedagency_profile_get
- First observedagency_profile_set
- First observedopportunity_audit
- First observedopportunity_compare
- First observedopportunity_discover
- First observedopportunity_export
- First observedopportunity_record_outcome
- First observedopportunity_search_history

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Scored 2026-07-28 09:25 across 8 tools

Disambiguation5/5

Each tool has a clear, distinct purpose without overlap. Profile tools manage the agency profile, opportunity discovery and audit are separated, and post-audit tools (compare, history, outcome, export) serve unique functions.

Naming Consistency5/5

All tools follow a consistent 'domain_action' pattern using snake_case, with 'agency_profile_' or 'opportunity_' prefixes and clear verbs (set, get, discover, audit, compare, search_history, record_outcome, export).

Tool Count5/5

8 tools align well with the server's purpose. Each tool covers a necessary step in the workflow from profile setup to discovery, audit, comparison, history, outcome recording, and export without being excessive or insufficient.

Completeness4/5

The tool set covers the main workflow comprehensively, but lacks explicit update/delete tools for audits or opportunities. There is also no direct listing of all opportunities, though search_history with filters partially addresses this.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MeSquared Visibility A
io.github.rmach816
Public-site SEO/AEO readiness scans with evidence scores, issues, and clear measurement scope.
Monitoring Marketing AI & Machine Learning
32
TrustGrowthOAuth
ai.trustgrowth
Site scores, audits, Search Console, keywords, competitors, authority and AI visibility tools.
Marketing Search Monitoring
1
ConquerorOAuth
com.conquerorapp
Turns SEO insight into page changes: keyword research, SERP and rank data, rewrites you approve.
Marketing Research & Data Content Management Systems
1
VibeSEOOAuth
dev.vibeseo
SEO research, audits, backlinks, GSC, and content workflow tools for AI agents.
Marketing Search
22

Related MCP Servers

Marketing Master – Landing
Marketing Web Scraping Testing & QA Tools
deeppath-ai
A
license
Not graded
quality
D
maintenance
Enables rapid analysis of landing pages for SEO compliance, conversion structure, color contrast accessibility, and performance metrics with automated optimization suggestions and code snippets.
Updated a year ago (2025-07-17 11:09 UTC)
11
1
MIT
SEO Analyzer API
Marketing Browser Automation
lazymac2x
F
license
Not graded
quality
D
maintenance
Analyzes any webpage for SEO scores, issues, and actionable recommendations. Supports side-by-side comparison of two URLs.
Updated 5 months ago (2026-04-11 00:58 UTC)
-
aso-audit-mcp
Developer Tools Browser Automation Testing & QA Tools
forgemeshlabs
A
license
A
quality
A
maintenance
Scans any website and produces an Agent Readiness Report scored on the open ASO framework.
Updated 9 days ago (2026-09-01 18:42 UTC)
5
359
2
MIT
Website Auditor MCP
Search Marketing
SpikeyCoder
A
license
A
quality
A
maintenance
Provides AI-visibility scoring and site auditing capabilities for websites, enabling agents to check how sites appear in AI engines like ChatGPT and Perplexity, run full SEO/security audits, and monitor changes over time.
Updated 2 days ago (2026-09-08 22:53 UTC)
15
505
MIT