Nordic Financial MCP

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

Annotations declare readOnlyHint=true and openWorldHint=false. The description adds that it orchestrates multiple searches internally and returns a synthesized narrative with source citations. It also details model options and costs. No contradictions; description enriches what annotations already provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a one-sentence summary, a sentence about internal orchestration, usage guidance, and a clear parameter list. Every sentence adds value, with no redundancy.

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

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

Given the tool's complexity (AI-powered analysis with internal orchestration), the description is complete: it covers scope (Nordic financial data, various report types), behavior (synthesized narrative with citations), model options, and alternatives. Output schema exists, so return values need no explanation.

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

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

Schema coverage is 100%, so the description doesn't need much, but it adds value by providing examples for company ('Equinor' or 'EQNR') and question ('How did margins develop 2022-2024?') and cost context for model parameter. This goes beyond the schema's basic descriptions.

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

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

The description clearly states it performs AI-powered company analysis using semantic search over Nordic financial data, returning synthesized answers with citations. It specifies the verb (analyze), resource (company), and domain (Nordic financial data), and distinguishes itself from sibling tools like search_filings and company_research.

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

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

Explicitly states when to use this tool ('when you want a synthesized answer rather than raw search chunks') and when not to use it, providing clear alternatives (search_filings, company_research). Also suggests an external server for full due diligence reports. This is exemplary guidance.

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

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

Description explains each query runs independently as hybrid search, results are raw chunks, and caller must synthesize. This adds detail beyond readOnlyHint and openWorldHint annotations, though annotations already cover basic safety.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with a clear intro, guidelines, and parameter explanations. Slightly verbose but each sentence adds value; front-loaded with purpose.

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

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

Covers all aspects: purpose, usage, parameters, return schema, edge cases (empty sections), and distinguishes from siblings. Output schema exists and is referenced appropriately.

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

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

Schema covers 100% of parameters. Description adds critical usage guidance: ticker filter reasoning, limit defaults/max, max sections, and concrete examples with queries.

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

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

Description explicitly states 'Run multiple targeted searches and return raw results grouped by section.' It contrasts with sibling 'analyze_company' and Alfred MCP server for orchestrated reports, making the tool's unique role clear.

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

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

Provides explicit when-to-use (caller defines sections) and when-not-to-use (for orchestrated report, use Alfred). Advises on ticker usage to avoid false positives and when to omit, plus example queries.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation and possibility of extra output fields. The description adds context by describing the return structure (dictionary with company name, status, address) and error handling ('Returns {'error': '<message>'} if not found...'). This provides behavioral detail beyond annotations, though the openWorldHint is not mentioned. There is no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a concise summary sentence, usage guidelines, parameter details with examples, and return value description. Every sentence adds value without redundancy. It is appropriately sized for the tool's complexity.

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

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

Given the tool's complexity (multi-country, format variations) and the presence of annotations and output schema, the description covers all necessary aspects: purpose, usage boundaries, parameter formats, and return behavior. It is complete and enables correct tool selection and invocation.

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

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

Schema coverage is 100%, with descriptions for both parameters. The description goes further by providing detailed format examples per country (e.g., 'NO: 9-digit organisation number, e.g. 923609016 (Equinor)'), which adds significant value beyond the schema alone. These examples help the agent understand correct input formats.

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

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

The description clearly states the tool's purpose: 'Look up a company in the official business registry for Norway, Denmark or Finland.' It uses a specific verb ('Look up') and resource ('company in the official business registry'). It also explicitly distinguishes itself from sibling tools by noting not to use for Sweden or for tickers/ISINs, directing to search_filings instead.

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

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

The description provides explicit guidance on when to use: 'Use this to retrieve authoritative registration data (legal name, status, address) for a known organisation number.' It also clearly states when NOT to use: 'Do not use for Sweden (SE)...' and 'Do not use to discover tickers or ISIN codes.' It suggests the alternative tool 'search_filings' for those cases.

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

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

Discloses key behaviors beyond annotations: return format with error handling, source differences between Norwegian zones and others, and timing of price publication. Annotations already indicate readOnlyHint=true, but description adds substantial context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear paragraphs and bullet points for args and returns. Every sentence adds value without redundancy.

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

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

Output schema exists, and description explains return values, error cases, and zone-specific behavior. Provides complete context for agent decision-making.

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

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

Schema covers both parameters fully (100%). Description adds meaning by listing zone options explicitly and explaining the behavior of include_tomorrow with respect to publication time.

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

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

Description clearly states the tool fetches today's hourly day-ahead electricity spot prices for Nordic bidding zones, with specific verb and resource. It distinguishes from sibling tool search_filings for historical analysis.

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

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

Explicitly states when to use (current/near-term) and when not (historical analysis), providing alternative tool and noting timing constraints for tomorrow's prices.

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

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

Annotations indicate readOnlyHint=true and openWorldHint=true, and the description adds behavioral details: returns error on download failure, invalid URL, or timeout; indicates '(no extractable text)' for scanned pages. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: clear purpose, usage guidelines, parameter details, and return value. No unnecessary sentences; every part earns its place.

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

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

Given a simple parameter set and existing output schema, the description fully covers the tool's behavior, including error cases and limitations. No gaps in context.

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

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

Schema coverage is 100% with one parameter (pdf_url). The description adds value beyond the schema by specifying the URL must be publicly accessible and that authentication-protected URLs will fail, plus an example format.

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

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

The description clearly states the tool's purpose: downloading a PDF from a URL and extracting text page by page. It uses specific verbs (download, extract) and defines the resource (PDF from URL), distinguishing it from sibling tools like search_filings.

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

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

The description provides explicit usage guidance: when to use (reading full text of a specific document, e.g., from search_filings), when not to use (PDFs well-represented in database, image-only PDFs), and suggests combining with search_filings.

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

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

Adds important behavioral context beyond the readOnlyHint annotation: the server can respond even if Qdrant is unavailable. Also describes the return value format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short paragraphs, each focused: purpose, usage guidelines, and return value. No unnecessary words.

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

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

For a simple ping tool, the description covers all needed aspects: purpose, when to use, parameter semantics, behavioral caveats, and return value.

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

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

The parameter 'name' is already well-described in the schema (100% coverage). The description adds context by linking the parameter to the response string ('included in the response').

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

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

The description clearly defines the tool as a 'connectivity check' for the Nordic MCP server, using specific verb and resource. It distinguishes from sibling tools by clarifying it is not a proxy for database health.

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

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

Explicitly states when to use ('at the start of a session'), when not to use (not as proxy for database health), and which alternative to use ('call search_filings directly').

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

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

Annotations declare readOnlyHint=true, and the description adds extensive behavioral context: database size (~1 million vectors, four markets), coverage periods, return format (chunked text excerpts reranked), and edge cases (empty list or Qdrant unreachable). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with headings and bullet points. Front-loaded with purpose and usage guidelines. Each section earns its place; no wasted text despite length.

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

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

Given 10 parameters (1 required), 100% schema coverage, and presence of an output schema, the description covers all aspects: purpose, usage, parameter details, return format, and edge cases. It is fully complete.

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

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

Schema coverage is 100%, so baseline is 3. The description's Args section adds meaningful examples and elaborates on parameter usage (e.g., query examples, sector values, report_type options) that go beyond the schema's brief descriptions.

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

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

The description clearly states the tool's purpose: 'Search the Nordic financial database for company filings, press releases and macroeconomic summaries.' It distinguishes from siblings like get_company_info (for Swedish registration data) and parse_pdf_to_text (for full documents).

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

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

Explicitly says when to use: 'Use this as the primary tool for any question about Nordic listed companies, markets or macro conditions.' Also provides exclusions: 'Do not use to retrieve a full document' and 'Do not use for Swedish company registration data', with alternative tools named.

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