VectorSmith

by kjgpta

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Tools like search_invoices, search_paid_invoices, and list_overdue_invoices heavily overlap since search_invoices already supports status filtering. Agents may struggle to choose between them, though get_invoice and count_invoices remain distinct.
Naming Consistency4/5
All tool names follow a lowercase snake_case convention with a verb_prefix pattern (get, list, search, count, run). Some verbs are interchangeable (list vs search) but the overall structure is predictable and readable.
Tool Count4/5
Seven tools is a reasonable count for an invoice-focused server, though two are meta-tools for dynamic discovery (list_available_tools, run_tool) which slightly muddles the domain focus. The core search/count tools are well-scoped.
Completeness2/5
The server is entirely read/search-focused with no create, update, or delete operations. It lacks invoice lifecycle management (e.g., creating, editing, or marking invoices paid), which is a significant gap for a billing-related tool surface.
Average 3.9/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on August 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the core function (searching paid invoices) but lacks details on read-only nature, pagination, default limits, or any side effects. The description adds little beyond the tool name itself.
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, front-loading the primary action and usage context. There is no fluff or redundant information, making it efficient and easily scannable.
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?
The tool has 4 parameters, no output schema, and no annotations. The description is minimal, explaining only the basic purpose and two of four parameters. It does not mention what the return value looks like, the behavior of the 'query' parameter, or how the 'limit' applies, leaving significant gaps for an agent to correctly invoke the tool.
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%, so the description must compensate. It explains the semantics of 'client' (filter by client) and 'amount' (min_amount), but completely omits the 'query' and 'limit' parameters. This partial coverage leaves two parameters unexplained, making the description insufficient for proper usage.
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 searches for paid invoices, using a specific verb and resource. It also distinguishes from sibling tools like search_invoices (which likely searches all invoices) by specifying 'already paid', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when the user asks about paid invoices or completed payments,' providing a clear context for when to invoke the tool. It does not mention when not to use it or alternatives, but the usage guidance is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the read-only listing behavior and optional filters, but doesn't mention return format, pagination, or how 'overdue' is defined. For a simple list operation, this is adequate but sparse.
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: the first states the purpose and filters, the second gives the usage trigger. No unnecessary words, well-structured.
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?
The tool is simple with 3 optional parameters, but the description only covers two of them, and there is no output schema or annotations. It lacks details about the 'limit' parameter and return structure, making the description incomplete for a fully informed 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?
Schema has 0% description coverage. The description mentions 'client' and 'minimum amount' but omits the 'limit' parameter entirely, and provides no additional semantic details about what 'client' refers to or how 'min_amount' is applied.
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?
Description states 'List overdue invoices only' – a specific verb and resource, and 'only' clearly scopes it to overdue invoices. This distinguishes it from siblings like search_invoices and search_paid_invoices by focusing on overdue status.
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?
Concludes with 'Use when the user asks which invoices are overdue or past due.' This provides a clear trigger for when to use the tool, but it doesn't explicitly list alternatives 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior, side effects, or permissions. It only says 'Search invoices,' implying a read operation, but gives no information about return format, pagination via limit, or any potential side effects. The description adds minimal behavioral context beyond the name and schema hints.
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: the first states the purpose and filters, the second gives usage context. There is no redundancy or fluff, and it is front-loaded with the core action. 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?
Given the tool has 5 optional parameters, no output schema, and no annotations, the description could be more thorough. It covers the main filters and usage context but lacks details on return format, pagination, and edge cases. The mention of 'Search invoices' implies a return, but without an output schema, the description should hint at the result type. It is adequate but not complete for an agent to use it without confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0% (no parameter descriptions), so the description should compensate. It mentions 'free text' (query), 'client', 'status', and 'amount' (likely min_amount), but omits the 'limit' parameter entirely. The mapping is partial; the description does not explain the exact meaning of min_amount or how the status filter works (e.g., multiple statuses selelectable). It adds some meaning but is incomplete.
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 action: 'Search invoices by free text and filter by client, status, or amount.' It identifies the resource (invoices) and the filtering capabilities, which distinguishes it from siblings like get_invoice (fetching specific) and list_overdue_invoices (specialized status). The verb 'search' plus the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear usage context: 'Use when the user asks about invoices, billing, or payments.' This tells the agent when to invoke it, but it does not explicitly mention when NOT to use it or point to alternatives like list_overdue_invoices or search_paid_invoices, which are more specialized. Thus it lacks explicit exclutions and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool fetches one invoice, implying a read operation, but doesn't disclose details like whether it returns full details, error behavior for invalid IDs, or any rate limits. It's minimal but not misleading.
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 action and parameter, and includes a usage hint. No wasted 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?
For a simple single-parameter fetch tool with no output schema, the description is sufficient. It covers the purpose, parameter, and usage context. It could mention what happens if the invoice is not found, but that's a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains the invoice_id parameter with an example format (INV-0001), which adds value beyond the schema. However, it doesn't specify the expected format beyond the example, so it's adequate but not rich.
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 fetches one invoice by invoice_id, with an example format (INV-0001). It distinguishes from siblings like search_invoices and list_overdue_invoices by specifying it's for a single known invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use when the user already has the invoice number, which provides clear context. It doesn't explicitly mention alternatives, but the sibling names imply other tools for searching or listing, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of transparency. It implies a read-only operation (counting) but does not explicitly mention side effects, permissions, or edge cases. For a simple count, this is acceptable, but it could be more explicit about returning a numeric result.
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 concise and well-structured, consisting of two clear sentences with no unnecessary details or fluff. It efficiently conveys the purpose and usage.
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 there is no output schema, the description could benefit from stating the return type (e.g., an integer count). However, the phrase 'Count invoices' strongly implies a numeric result, making the tool's behavior sufficiently clear for typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal value beyond the input schema. It merely restates that client and status are optional filters, without explaining their exact semantics (e.g., how client is matched, whether status accepts multiple values). The schema already provides types and enums, so the description contributes little to parameter understanding.
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 that the tool counts invoices, and it explicitly says to use it when the user asks how many invoices exist. This effectively distinguishes it from sibling tools like search_invoices or get_invoice, which return detailed data rather than a count.
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 guidance on when to use this tool: 'Use when the user asks how many invoices there are.' It also mentions optional filters, implying it can be used with or without them, which clarifies its flexibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no insight into potential side effects, read-only guarantees, or whether the tool mutates state. Since it can invoke any tool, side effects are unknown, risking unintended writes.
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, directly to the point, with no redundant information or filler.
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?
It explains what the tool does and when to use it, but does not describe the return value or output format. Since it's a generic launcher, it might be expected to return the called tool's result, but that is not stated. Acceptable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are clear: name is a tool name from list_available_tools, arguments match that tool's inputSchema. This adds helpful context beyond basic types, though it could mention required vs optional fields.
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 runs any VectorSmith tool by name with arguments, which is specific and distinguishes it from the invoice-specific 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this for tools added to tools.yaml after Claude connected, and notes that Desktop won't show those names, giving clear when-to-use guidance versus alternatives.
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?
With no annotations, the description carries the full burden of behavioral transparency. It discloses that the tool fetches live data from tools.yaml, including newly added tools, and warns about a frozen connector list. This conveys dynamic, read-only behavior without explicit side effects, which is sufficiently transparent for a list operation.
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 concise, consisting of two sentences that convey the tool's purpose, a key behavioral nuance, and a practical usage tip. There is no redundant information, and every sentence serves a clear function, making it well-structured and easy to parse.
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?
Given the simplicity of the operation (listing tools) and the absence of an output schema, the description provides sufficient context. It explains when to call the tool, what it returns (a live list), and why it matters (frozen connector list). This fully equips the user to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is complete (100%). The description does not need to explain any parameters. Since no parameter information is added, the baseline score of 3 applies, indicating no additional semantic value provided 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 that the tool provides a live list of available tools from the current tools.yaml, including tools added after the chat started. It explicitly distinguishes itself from sibling tools by focusing on enumeration of tools, making the purpose unmistakable.
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 gives explicit guidance on when to use this tool: 'call this before saying a tool is missing, then invoke with run_tool.' It also explains the context of Claude Desktop freezing the connector list, which clarifies why a live refresh is needed. This effectively directs the user to prefer this tool over alternatives in a specific scenario.
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

Copy to your README.md:

[![vectorsmith MCP server](https://glama.ai/mcp/servers/kjgpta/vectorsmith/badges/card.svg)](https://glama.ai/mcp/servers/kjgpta/vectorsmith)

Score Badge

Copy to your README.md:

[![vectorsmith MCP server](https://glama.ai/mcp/servers/kjgpta/vectorsmith/badges/score.svg)](https://glama.ai/mcp/servers/kjgpta/vectorsmith)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/kjgpta/vectorsmith'

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