Skip to main content
Glama
dsouza-anush

Exa MCP Server

by dsouza-anush
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Server Quality Checklist

67%
Profile completionA complete profile improves this server's visibility in search results.

  • Latest release: v1.0.0

  • Disambiguation5/5

    The two tools have clearly distinct purposes: get_code_context_exa is specialized for programming-related searches with high-quality, fresh context for code, libraries, SDKs, and APIs, while web_search_exa is a general web search tool for real-time information and URL scraping. There is no overlap in functionality, making it easy for an agent to select the correct tool based on the query content.

    Naming Consistency5/5

    Both tools follow a consistent naming pattern: they use snake_case and start with a verb (get, search) followed by a noun (code_context, web), with a suffix (_exa) to indicate the server. This uniformity makes the tool names predictable and easy to understand, enhancing usability.

    Tool Count2/5

    With only 2 tools, the server feels thin for its apparent scope of providing search capabilities via Exa AI. While the tools cover distinct areas (code and general web), a typical search server might benefit from additional tools for more granular operations (e.g., filtering, advanced queries) or other domains, making this count borderline too few for robust functionality.

    Completeness3/5

    The server covers basic search needs with tools for code-specific and general web searches, but there are notable gaps. For example, it lacks tools for updating or managing search results, handling different content types beyond code and web pages, or providing configuration options beyond result counts. This limits the surface for more complex agent workflows, though core search functionality is present.

  • Average 4.3/5 across 2 of 2 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 0 commits in the last 12 weeks
    • No stable releases found
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI is passing

  • This repository is licensed under MIT License.

  • This repository includes a README.md file.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • Add a glama.json file to provide metadata about your server.

  • If you are the author, simply .

    If the server belongs to an organization, first add glama.json to the root of your repository:

    {
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}

    Then . Browse examples.

  • Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

  • Behavior4/5

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

    The description adds valuable behavioral context beyond what annotations provide. While annotations indicate read-only, idempotent, and non-destructive operations, the description specifies real-time capabilities, scraping functionality, configurable result counts, and relevance-based content return. This enhances the agent's understanding of the tool's operational characteristics.

    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 efficiently structured in two sentences that front-load the core functionality. Every phrase adds value: the first sentence establishes the primary action and key capabilities, while the second sentence highlights configurable aspects and return behavior. There's no wasted language or redundancy.

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

    Completeness4/5

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

    Given the tool's moderate complexity (5 parameters, real-time operations), the description provides good context about what the tool does and key capabilities. While there's no output schema, the description mentions what gets returned ('content from the most relevant websites'). The combination of good annotations and descriptive text makes this reasonably complete, though more detail about result format would enhance it further.

    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, the input schema already documents all 5 parameters thoroughly. The description mentions 'configurable result counts' which aligns with the numResults parameter, but doesn't add significant semantic value beyond what's already in the structured schema. The baseline of 3 is appropriate when schema coverage is complete.

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

    Purpose5/5

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

    The description clearly states the tool's purpose with specific verbs ('Search the web', 'scrape content from specific URLs') and resources ('using Exa AI', 'websites'). It distinguishes itself from the sibling tool 'get_code_context_exa' by focusing on general web search rather than code-specific context retrieval.

    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 provides clear context about when to use this tool ('performs real-time web searches', 'can scrape content from specific URLs'), but doesn't explicitly mention when NOT to use it or provide specific alternatives. The sibling tool name suggests a more specialized code-focused search, but this distinction isn't articulated in the description.

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

  • Behavior4/5

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

    Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read operation. The description adds valuable context about Exa-code's quality ('highest quality and freshest context') and scope ('libraries, SDKs, and APIs'), which enhances behavioral understanding beyond the annotations.

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

    Conciseness4/5

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

    The description is front-loaded with key information (purpose and quality) and includes a clear usage rule, all in three sentences. It's efficient with minimal waste, though the mandatory rule phrasing could be slightly more concise.

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

    Completeness4/5

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

    Given the tool's complexity (search with token control), rich annotations (read-only, idempotent, non-destructive), and 100% schema coverage, the description is mostly complete. It lacks details on output format or pagination, but with annotations covering safety and schema covering inputs, it provides sufficient context for effective 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?

    Schema description coverage is 100%, so the schema fully documents both parameters (query and tokensNum). The description doesn't add any parameter-specific semantics beyond what's in the schema, such as examples or usage tips for the parameters, so it meets the baseline of 3.

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

    Purpose5/5

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

    The description clearly states the tool's purpose with specific verbs ('Search and get relevant context') and resources ('programming task', 'libraries, SDKs, and APIs'), and explicitly distinguishes it from its sibling tool by emphasizing its specialization in code-related searches versus the more general 'web_search_exa'.

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

    Usage Guidelines5/5

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

    The description provides explicit usage guidelines: 'Use this tool for ANY question or task related to programming' and includes a mandatory rule ('MUST use this tool') when the query contains code-related terms. It clearly differentiates when to use this tool versus alternatives by focusing on programming contexts.

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

GitHub Badge

Glama performs regular codebase and documentation scans to:

  • Confirm that the MCP server is working as expected.
  • Confirm that there are no obvious security issues.
  • Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

exa-mcp-server-heroku MCP server

Copy to your README.md:

Score Badge

exa-mcp-server-heroku MCP server

Copy to your README.md:

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dsouza-anush/exa-mcp-server-heroku'

If you have feedback or need assistance with the MCP directory API, please join our Discord server