reai-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource or action: identity, tenant selection, reference data (VAT codes, accounts), transactions (vouchers, postings), reports (general ledger), and API discovery/invocation. Even the three API exploration tools (search_endpoints, describe_endpoint, list_api_tags) serve clearly different purposes: finding, schema-documentation, and high-level orientation.
Naming Consistency4/5
The vast majority follow a consistent verb_noun pattern with the reai_ prefix (list_accounts, get_voucher, search_endpoints, use_tenant). Minor deviations are reai_whoami (idiomatic command rather than verb_noun) and reai_general_ledger (noun-only, implying a 'get' verb), but these are easily understood and do not disrupt the overall coherence.
Tool Count5/5
With 12 tools, the set is well-scoped for an accounting domain. Each tool has a clear role, and the number is within the ideal 3–15 range. The inclusion of both curated tools and an escape hatch (reai_request) balances usability with power without bloating the surface.
Completeness5/5
The curated tools cover the core read-side lifecycle: tenant management, reference data (accounts, VAT codes), vouchers (list/get), postings, and the general ledger report. The reai_request tool fills any gap by allowing direct API calls after discovery via reai_search_endpoints/reai_describe_endpoint, ensuring no dead ends for write or uncommon operations.
Average 4.4/5 across 12 of 12 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 190 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the behavioral detail that the result includes postings and attachments, which goes beyond the basic fetch semantics but doesn't disclose any additional side effects, permissions, or rate limits. This is consistent with the annotations and adds moderate context, but not rich behavioral disclosure.
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, front-loaded sentence that states the core action and the key included data. It is concise with no filler or redundancy.
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 single-fetch operation, the description covers the essential information: what is fetched (voucher by id) and what is included in the result (postings and attachments). The schema handles parameter details and annotations cover the read-only nature, so the description is sufficiently complete for an agent to invoke it 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?
Schema coverage is 100%, with both parameters already having descriptive text, including a helpful note on tenantId referencing reai_use_tenant and reai_whoami. The tool description itself adds no parameter-specific meaning beyond what the schema provides, so it meets the baseline three for high 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 explicitly states the verb ('Fetch'), the resource ('a single voucher by id'), and the scope ('including all its postings and attachments'). This clearly distinguishes it from sibling tools like reai_list_vouchers, which list multiple vouchers, and reai_list_postings, which list postings separately.
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 does not explicitly name alternatives or state when not to use the tool. However, the phrase 'by id' clearly implies this is for fetching a specific known voucher, and the sibling names like reai_list_vouchers suggest the alternative for listing. That said, there is no explicit 'use this instead of...' guidance, so the usage context is only implied.
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 and destructiveHint=false, covering safety. The description adds value beyond annotations by revealing that each posting reports canDelete and lockReasons, and by stating the default calendar-year date range.
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 dense sentences front-load the core action and resource, then add filters and behavioral details. Every sentence earns its place with no 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?
The description covers the core operation, filter options, default date range, and a notable response characteristic (canDelete/lockReasons). It does not mention pagination or sorting, but for a read-only list tool with no output schema, this is reasonably complete.
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 coverage is 100% with individual descriptions for all 10 parameters. The description groups filters semantically (account, voucher, customer, etc.) but does not add new meanings beyond the schema, so the baseline 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 a list operation on individual ledger postings with a date range and multiple optional filters. It distinguishes from sibling tools like reai_list_vouchers and reai_general_ledger by specifying 'individual ledger postings'.
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 context through the date range and optional filters, but it does not explicitly say when to use this tool versus alternatives like reai_list_vouchers or reai_general_ledger. No exclusions or when-not-to-use guidance is provided.
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 and destructiveHint=false; the description reinforces the read operation and adds a performance warning ('a full-year ledger ... can be large') that encourages filtering. It also clarifies the report content — accounts with opening/closing balances and postings — which goes beyond the schema. No contradiction found.
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, front-loaded with the action and result, followed by usage examples and a performance tip. Every sentence earns its place with no filler or repetition.
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 complexity of 13 optional parameters and no output schema, the description covers the core usage: period, account narrowing, size warning, and example queries. It does not describe the exact result structure, but the general ledger report is well enough characterized to inform correct invocation.
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 input schema covers all 13 optional parameters (100% coverage), so the baseline applies. The description adds meaningful guidance on account-selection parameters ('Narrow with accountNumber or an account range'), but it does not explain the other filters in detail. This is adequate but not exceptional.
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 'Read the general ledger for a period' — a specific verb, resource, and scope — and lists the outputs ('opening balance, postings and closing balance'). It also gives concrete example questions ('what did we spend on X') that position it clearly against sibling list 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 explicitly states when to use it: 'This is the report to use for questions like...' It also advises narrowing with accountNumber or an account range due to potential size. However, it does not name sibling alternatives or state when not to use it, so it stops short of full when/when-not guidance.
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 indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds context by stating the return fields (account numbers, names, types) and the operational requirement that postings must reference accounts from this list. This is useful context beyond the annotations, though it doesn't detail pagination or edge cases.
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 core action and object. Every sentence provides value: the first defines what it does, the second explains why and when to use it. No redundant or filler content.
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 compensates by stating the return fields (account numbers, names, types) and providing a clear use case. It doesn't explain the exact response structure or how pagination works, but the schema covers parameters and the description covers the essentials for a read-only search tool.
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 parameters (limit, query, tenantId, accountNumberPrefix) are fully documented in the schema. The description doesn't add specific parameter-level meaning but aligns with the search intent. Baseline of 3 is appropriate.
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 a specific verb ('Search') and resource ('tenant's chart of accounts'). It distinguishes itself from siblings like reai_list_vat_codes and reai_list_postings by mentioning the return of account numbers, names, and types, and by tying it to voucher bookings.
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 when to use the tool ('Use this to find the right account number before booking a voucher') and gives a compelling rationale ('every posting must reference an account that exists in this list'). It doesn't explicitly mention when not to use or name alternatives, but the context is clear enough.
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 mark the operation as read-only and non-destructive. The description adds valuable behavioral details: it defaults to the current calendar year if dates are omitted, and it returns each voucher with its postings, which is not visible in 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 three sentences, front-loaded with the primary action, and each sentence provides necessary context: the operation, the domain concept, and the default behavior. 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 list tool with six optional parameters and detailed schema descriptions, the description provides the core purpose, domain definition, and default behavior. It lacks details on response format or pagination, but with no output schema and read-only annotations, it is reasonably complete.
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 coverage is 100%, so the baseline is 3. The description mentions date range defaults, but these are already documented in the schema's startDate and endDate descriptions, so no new parameter semantics are added.
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 lists vouchers within a date range, including their postings, and defines the voucher concept. This distinguishes it from sibling tools like get_voucher (single item) and list_postings (postings only).
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 for when to use the tool: listing vouchers with postings in a date range, with defaults for date bounds. However, it does not explicitly mention alternatives or when not to use it, 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds behavioral context that results vary by tenant and the set is tenant-specific, which is beyond what 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?
Two sentences, front-loaded with the action and content, with a rationale sentence that earns its place by motivating use. No superfluous information.
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 list tool with comprehensive annotations and schema, the description covers what, why, and scope. Even without an output schema, it provides enough context for the agent to select 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?
Schema descriptions cover 100% of parameters, so the description doesn't need to add parameter details. The tenant mention in the description aligns with tenantId, but the usage parameter is left entirely to 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 a specific verb ('List') and resource ('VAT codes') with scope ('available in this tenant') and content ('rate, type and description'). This distinguishes it from sibling tools like reai_list_accounts and reai_list_vouchers.
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 instructs to use the tool to look up VAT codes rather than guessing, explaining that postings require them and the valid set depends on tenant VAT registration. It doesn't name an alternative tool but provides clear when-to-use context.
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 provide readOnlyHint, idempotentHint, and destructiveHint, but the description adds crucial behavioral context: the setting persists for the session, the tenantId is validated against reachable tenants (preventing typos), and per-tool overrides are possible. This goes 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?
Two concise sentences with the main action front-loaded, followed by valuable context (validation and override behavior). Every sentence earns its place with no 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?
For a simple one-parameter tool with no output schema, the description fully covers the session effect, validation safeguards, and interaction with other tools. No important context is missing.
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%, and the schema already describes tenantId as the 'Tenant id to make active' and suggests using reai_whoami for valid ids. The description adds no further parameter semantics, so baseline 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 uses a specific verb ('Set') and resource ('tenant (company)'), clearly distinguishing this from sibling tools like reai_whoami which queries tenant info. It states exactly what the tool does: establishes the active tenant for subsequent 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 description explains the session-scoped nature ('for the rest of this session') and that individual tools can override the setting, providing clear context for when to use it. It doesn't explicitly state exclusions or alternative tools, but the context is sufficient.
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 and openWorldHint, covering the safety profile. The description adds behavioral context by stating the output includes operation counts and serves as a map of the accounting system's capabilities, which goes beyond the structured hints. It does not contradict any 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?
Two tightly written sentences: the first states the action and resource, the second gives the use case. There is no filler, redundant exposition, or over-explanation. The structure is front-loaded with the primary verb.
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 no-parameter, no-output-schema tool, the description is sufficiently complete. It explains what is returned (list of domains with operation counts) and why it's useful. The annotations cover safety constraints, so nothing critical is missing for an agent to decide whether to invoke it.
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, and the schema description coverage is 100% vacuously. Per the baseline for zero-param tools, a score of 4 is appropriate; the description doesn't need to explain parameters. It still adds output context (operation count), but that's not parameter-specific.
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 uses the specific verb 'List' with a clear resource ('every documented ReAI API domain (tag)') and adds 'with its operation count', making the tool's purpose unambiguous. It also distinguishes this from sibling tools by framing it as 'a map of what the accounting system can do', which signals a high-level discovery function rather than a specific endpoint or account listing.
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 a clear usage context: 'Useful for orienting before a search.' This implies it should be used first to understand available domains. However, it does not explicitly mention when to avoid this tool or name alternatives (e.g., reai_search_endpoints), so it stops short of full exclusion guidance.
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?
The description discloses the return format (path, parameters, request-body field names) and warns that internal endpoints are off by default. This adds context beyond the readOnlyHint annotation, which already indicates a safe read operation. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four compact sentences with no fluff. It front-loads the core function, gives concrete examples, and outlines the workflow, all in an efficient structure.
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 search tool with optional parameters and no output schema, the description covers scope, when to use, return format, and next steps. It lacks only minor details like pagination behavior, but the limit parameter is already documented in the schema.
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 100%, so baseline is 3. The description adds extra value by explaining that Norwegian domain terms often appear in descriptions and English in paths/tags, aiding query construction. It also clarifies the interaction between query and tag 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 searches the full ReAI OpenAPI surface by keyword, tag, or HTTP method, listing concrete example domains. It distinguishes itself from sibling tools like reai_describe_endpoint and reai_request by positioning itself as the initial discovery step.
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?
Explicit guidance says to use this whenever no curated tool covers the need, and provides a follow-up workflow: use reai_describe_endpoint for full schemas, then call via reai_request. This clearly differentiates from curated tools and alternatives.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral detail beyond annotations by specifying output contents ('every parameter, the full request body with nested objects resolved, and response shapes'), which helps an agent understand what to expect when invoking the tool. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by practical usage guidance. Every word earns its place; there is no repetition of schema details or annotations.
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?
The tool is simple (3 parameters, no output schema), and the description is sufficient: it explains what the tool returns, when to use it, and why it matters. It also provides enough context to distinguish it from sibling tools without needing to enumerate alternatives.
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 provides 100% description coverage for all three parameters (method, path, depth) with clear explanations. The description does not add meaningful parameter-level semantics beyond the schema, so the baseline 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 uses a specific verb ('Get') and clearly identifies the resource ('complete schema for one ReAI endpoint'). It explicitly lists what the tool returns (every parameter, full request body with nested objects resolved, response shapes) and is easily distinguished from sibling tools like reai_search_endpoints.
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 states exactly when to use the tool: 'Use this before calling an unfamiliar endpoint with reai_request, especially for POST and PUT where required fields matter.' This names the companion tool (reai_request) and gives a concrete condition (unfamiliar endpoints, POST/PUT), providing clear guidance versus alternatives.
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?
Even though annotations already indicate destructiveHint=true and openWorldHint=true, the description adds critical behavioral details: authentication and tenant header are handled automatically, write calls are subject to server write policy, and unrecognized write paths are treated as irreversible and blocked unless REAI_WRITE_MODE=full. This goes beyond the annotations to warn the agent about safety and policy enforcement.
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, front-loaded, and every sentence earns its place. It covers purpose, usage workflow, and safety policy without unnecessary filler. The structure flows logically from 'what' to 'how' to 'warnings'.
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 high-risk escape-hatch tool with no output schema, the description provides complete guidance: how to use it, how to discover endpoints, how to check schemas, how authentication works, and what safety restrictions apply. It is fully contextualized within the sibling toolset and self-sufficient for an agent to use it 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?
Schema description coverage is 100%, so the input schema already documents all parameters and their meanings. The description adds no additional parameter-specific semantics beyond clarifying that authentication/tenant header are handled, which helps with tenantId but is a minor addition. Baseline 3 is appropriate.
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 'Escape hatch: call any ReAI API endpoint directly,' which clearly states the verb (call), resource (any ReAI API endpoint), and scope. It distinguishes itself from curated tools by noting it covers what they do not, and provides a clear path to discovery via reai_search_endpoints and reai_describe_endpoint.
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 to use it for anything the curated tools do not cover, and advises discovering endpoints and checking schemas first. This gives clear when-to-use guidance and names alternative tools (reai_search_endpoints, reai_describe_endpoint) as prerequisites, effectively explaining a safe workflow.
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?
Even with readOnlyHint and destructiveHint annotations, the description adds valuable context: it reports the active tenant and the server's write policy, and clarifies that the tenant list includes id, slug, and currency. This goes beyond the annotations and sets accurate expectations.
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, front-loaded with the core purpose, and the second sentence provides crucial usage context. Every phrase earns its place without 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?
Despite lacking an output schema, the description fully conveys what the tool returns (user identity, tenant list with fields, active tenant, write policy). It also provides essential session context, making it complete for a zero-parameter tool in this sibling set.
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 and an empty schema, so the description carries no parameter burden. It appropriately describes the tool's role without needing to explain inputs, meeting the baseline for parameterless tools.
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 uses specific verbs ('Identify' and 'list') and clearly states the resource (the authenticated ReAI user and every accessible tenant). It distinguishes itself from siblings by focusing on session initialization and tenant discovery, which no other sibling tool does.
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 explicitly says 'Call this first in any session' and explains why: most other tools are tenant-scoped and require the tenant id. This provides clear when-to-use guidance and effectively positions it relative to tenant-scoped siblings.
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:

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

Score Badge

Copy to your README.md:

[![reai-mcp MCP server](https://glama.ai/mcp/servers/Stener1/reai-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Stener1/reai-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/Stener1/reai-mcp'

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