voygr-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool has a distinct role: verification, credit check, call placement, consent, mid-call answer, and status retrieval. The only potential overlap is verify_place vs verify_places, but the singular/plural distinction is clearly explained in the descriptions.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (verify_place, check_credits, call_place, approve_call, answer_mid_call, get_call), with no naming style mixing.
Tool Count5/5
Seven tools is well-scoped for a place-verification and calling service. Each tool covers a distinct step in the workflow with no redundancy.
Completeness4/5
The surface covers the full workflow: verify places, place calls, handle consent, relay mid-call answers, and retrieve status. Minor gaps like canceling a call or listing history are not critical for the core purpose.
Average 4.5/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
- 14 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing side effects. 'Get status/outcome' strongly implies a read-only operation, but it does not explicitly state 'read-only', nor does it describe error cases, auth requirements, or whether the operation is safe to repeat. The 'async recovery path' hint adds some context but not enough behavioral detail.
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, front-loaded with the action and resource, and contains no filler. Every word contributes to understanding the tool's purpose and usage context.
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 only one parameter and an output schema (not shown), the description covers the essential context: the origin of the call handle and the async recovery path. It is slightly thin on explicit usage guidance or alternative tools, but for a simple getter, the provided context is largely sufficient.
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 input schema only lists 'call_id' as a string. The description adds meaning by linking this ID to 'a call handle returned by call_place', which clarifies what value to pass and where it originates. This goes beyond the schema's bare title, effectively compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get status/outcome'), the resource ('a call handle'), and the context ('returned by call_place (async recovery path)'). This differentiates it from sibling tools like call_place (which places the call) and verify_place (which likely verifies a place). The verb+resource+context is specific and 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 implies when to use this tool: after call_place returns a handle, and specifically in async recovery scenarios. It does not explicitly mention alternatives or exclusion criteria, but the context is clear enough for an agent to infer the appropriate usage.
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 must disclose behavior. It mentions deduplication and caching on normalized name+address, which is useful. However, it does not explain what verification entails, potential side effects, or error behavior, leaving gaps.
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 only two sentences, front-loaded with the primary action, and includes no filler. Every phrase adds value.
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 tool with a single parameter and an output schema, the description covers purpose, input format, behavioral nuances, and usage context. It could be more explicit about when to choose this over 'verify_place,' but overall it is sufficient.
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 only shows a generic array of objects with string properties. The description adds essential semantics: 'Input a list of {name, address},' specifying the expected keys and structure, which is critical given the schema lacks descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Verify multiple places,' which clearly specifies the verb (verify), resource (places), and scope (multiple), effectively distinguishing it from the singular 'verify_place' sibling.
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 before recommending options.' This indicates when to call the tool, though it does not explicitly mention when not to use it or contrast it with 'verify_place' beyond the plural implication.
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, the description carries the full behavioral disclosure burden. The verb 'Report' implies a read-only operation, and the description identifies the type of data returned (usage/credits). However, it does not explicitly confirm no side effects, mention any authorization needs, or describe potential failure modes. This is adequate but not rich.
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 concise sentence of 14 words. It front-loads the core action ('Report VOYGR usage/credits') and follows with the purpose. Every word earns its place; there is no redundancy or fluff.
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 tool's simplicity (zero parameters) and the presence of an output schema, the description provides sufficient context. It names the resource type (VOYGR usage/credits) and the intended use case (explain spend and holds). The output schema can handle return-value details, so no additional description is necessary.
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 tool has zero parameters, so the schema coverage is 100% by default. Per the scoring rules, 0 parameters merits a baseline of 4. The description adds no parameter-related meaning because there are no parameters to explain. No deduction 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?
The description clearly states the tool's function: 'Report VOYGR usage/credits'. The verb 'Report' is specific and the resource ('VOYGR usage/credits') is explicit. It also conveys the intended outcome ('so the agent can explain spend and holds'), which adds purpose. This distinguishes it from sibling tools focused on places and calls.
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 phrase 'so the agent can explain spend and holds' provides clear context for when to use this tool: when the agent needs to answer questions about spending or holds. However, it does not explicitly mention when not to use it or name alternative tools, though sibling tools are clearly unrelated to credits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 and does so well. It discloses that the return value is a 'verdict/recommend' rather than raw data, warns against trusting 'open_closed' alone, and explicitly notes the cost of 1 credit. This goes beyond the schema and gives the agent important operational 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 two sentences with no filler. The first sentence states the core purpose; the second adds return behavior, a critical reliability warning, and cost information. Every sentence earns its place, and the description is front-loaded with the primary action.
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?
The tool has an output schema, so the description need not detail return values; it appropriately mentions 'verdict/recommend' as a preview. It covers cost and the reliability caveat. It does not mention prerequisites like credit checking or typical failure modes, but given the output schema and simple 2-parameter input, this is not a significant 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%, so the description must compensate. It indirectly references the parameters ('named place' and 'address') but does not define their format, constraints, or examples. The parameter names themselves are self-explanatory, and the description ties them to the tool's purpose, providing minimal added meaning. A score of 3 reflects that it is 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 a specific verb ('verify') and resource ('a named place at an address'), and defines the scope as checking existence and operating status. This distinguishes it from siblings like call_place or get_call, though not explicitly from verify_places.
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 on when to use this tool: whenever one needs a trusted verdict on a place's operating status, since 'never trust raw open_closed alone.' It also mentions a cost (1 credit), implying the agent should consider resource usage. It does not explicitly exclude alternatives or list when-not-to-use scenarios, so it falls short of a 5.
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. It discloses a critical behavioral constraint: 'Only works with a server-issued token — do not invent one.' This warns against fabricating tokens and implies invalid tokens will fail. It does not detail failure modes or side effects, but the key restriction is transparent.
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?
Three sentences, each purposeful: purpose, usage, and a warning. No redundant wording. The structure front-loads the action and contextualizes the token requirement efficiently.
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 single-parameter tool with an output schema present, the description covers what, when, and how—leaving no critical gaps. The warning about server-issued tokens addresses a potential misuse. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines consent_token as a required string. The description adds essential semantics: the token is returned by call_place when error=consent_required. This tells the agent exactly where the value comes from and how to obtain it, going well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Approve a pending call after the human said yes in chat.' It specifies the action (approve) and the resource (pending call), and the mention of consent_token ties it to a specific workflow, distinguishing 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context: 'after the human said yes in chat' and 'when error=consent_required.' It also provides a concrete reference to call_place, but does not explicitly name alternatives or when-not-to-use scenarios. The guidance is strong but not exhaustive.
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?
No annotations are provided, so the description carries the full burden. It discloses the mid-call handoff nature and the instruction not to invent the answer or token. However, it does not mention any side effects, return behavior, or whether the call ends after this, but it is generally transparent for a relay tool.
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 long and front-loaded with the purpose. Every sentence adds value: the first states what it does and when, the second explains the workflow and a critical warning. No unnecessary words.
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 simple tool with 2 parameters, the description covers purpose, usage conditions, parameter meaning, and behavioral constraints. An output schema exists, so return values are already structured. Sibling context is not needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the input schema provides no descriptions for 'answer_token' or 'answer'. The description compensates by defining the token as coming from call_place/approve_call and the answer as the human's response. It doesn't specify formats or constraints, but gives enough context to understand both parameters.
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: 'Relay the human's answer to a mid-call venue question.' It uses a specific verb ('relay') and resource ('human's answer'), and distinguishes itself from siblings by referencing the call_place/approve_call status and the mid-call handoff.
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?
It explicitly says when to use the tool: 'When call_place/approve_call returns status=awaiting_mid_call_answer.' It provides a clear sequence of actions (show question to human, then call with token and answer) and even warns against inventing the answer or token. This is excellent usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavior disclosure burden. It explains consent handling, return values like consent_required and awaiting_mid_call_answer, the absence of a confirm boolean, and dry-run simulation behavior. These details go beyond what annotations would typically provide and give the agent a realistic model of the tool's runtime behavior.
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 dense but every sentence provides actionable information: purpose, intents, language, slot requirements, consent flow, mid-call answer flow, confirm boolean absence, and dry-run behavior. There is no fluff or repetition, and it is front-loaded with the core purpose. This is an excellent balance of detail and brevity.
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?
This is a complex tool involving consent workflows, mid-call interactions, and dry-run behavior. The description covers the critical operational flows and return states. While it does not spell out the success return shape, an output schema is present, so that information is not required in the description. The description is sufficiently complete for safe and correct invocation.
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 provides no descriptions (0% coverage), so the description must compensate. It explains the intent values, the required slot (question) for inquiry, and that language is restricted to 'en'. It also clarifies that there is no confirm boolean. However, it does not explain the meaning of all parameters (e.g., kind, venue, phone, slots keys), leaving some gaps for a few parameters.
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 opens with a specific verb and resource: 'Place a structured outbound VOYGR call to a venue phone.' This clearly states what the tool does and distinguishes it from sibling tools like approve_call or answer_mid_call, which are follow-up actions. It further clarifies the two intents (inquiry and info_gathering), leaving no ambiguity about the primary function.
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 guidance, including when to use alternative tools: if consent is required, 'call approve_call'; if a mid-call question arises, 'answer_mid_call'. It also sets a clear precondition for the inquiry intent (slots must include a question) and states that party_size/date/time alone are insufficient. This gives the agent actionable decision rules.
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:

[![voygr-mcp MCP server](https://glama.ai/mcp/servers/VaarunSinha/voygr-mcp/badges/card.svg)](https://glama.ai/mcp/servers/VaarunSinha/voygr-mcp)

Score Badge

Copy to your README.md:

[![voygr-mcp MCP server](https://glama.ai/mcp/servers/VaarunSinha/voygr-mcp/badges/score.svg)](https://glama.ai/mcp/servers/VaarunSinha/voygr-mcp)

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/VaarunSinha/voygr-mcp'

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